DBMS & Internet Programming Notes
Database Management System
Introduction to Database : A database is a collection of stored
operational data used by various applications and/or users by some
particular enterprise or by a set of outside authorized
applications and authorized users.
DataBase Management System : A DataBase Management System (DBMS)
is a software system that manages execution of users applications
to access and modify database data so that the data security, data
integrity, and data reliability is guaranteed for each application
and each application is written with an assumption that it is the
only application active in the database.
What Is Data ? Different view points: A sequence of characters
stored in computer memory or storage Interpreted sequence of
characters stored in computer memory or storage Interpreted set of
objects Database supports a concurrent access to the data File
Systems : File is uninterpreted, unstructured collection of
information File operations: delete, catalog, create, rename, open,
close, read, write, find, Access methods: Algorithms to implement
operations along with internal file organization Examples: File of
Customers, File of Students; Access method: implementation of a set
of operations on a file of students or customers. File Management
System Problems : Data redundancy Data Access: New request-new
program Data is not isolated from the access implementation
Concurrent program execution on the same file Difficulties with
security enforcement Integrity issues .
ADVANTAGES OF A DBMS:Data independence: Application programs
should be as independent as possible from details of data
representation and storage. The DBMS can provide an abstract view
of the data to insulate application code from such details.client
data access: A DBMS utilizes a variety of sophisticated techniques
to store and retrieve data efficiently. This feature is especially
important if the data is stored on external storage devices.Data
integrity and security: If data is always accessed through the
DBMS, the DBMS can enforce integrity constraints on the data. For
example, before inserting salary information for an employee, the
DBMS can check that the department budget is not exceeded. Also,
the DBMS can enforce access controls that govern what data is
visible to different classes of users.Data administration: When
several users share the data, centralizing the administration of
data have more significant improvements. Experienced professionals
who understand the nature of the data being managed, and how
different groups of users use it, can be responsible for organizing
the data representation to minimize redundancy and for ne-tuning
the storage of the data to make retrieval efficient.Definition 1: A
database management system (DBMS) is a general purpose system
software facilitating each of the following (with respect to a
database): 1. defining: specifying data types, data organization,
and constraints to which the data must conform 1. constructing: the
process of storing the data on some medium (e.g., magnetic disk)
that is controlled by the DBMS 1. manipulating: querying, updating,
report generation 1. Sharing: a database allows multiple users and
programs to database concurrently.1.
Protection&security:protection from hardware and software
crashes and security from unauthorized accessDefinition 2: Database
management system is software of collection of small programs to
perform certain operation on data and manage the data.Two basic
operations performed by the DBMS are: Management of Data in the
Database Management of Users associated with the
database.Management of the data means to specify that how data will
be stored, structured and accessed in the database. Management of
database users means to manage the users in such a way that they
can perform any desired operations on the database. DBMS also
ensures that a user can not perform any operation for which he is
not allowed. And also an authorized user is not allowed to perform
any action which is restricted to that user. In General DBMS is a
collection of Programs performing all necessary actions associated
to a database.Differences of the Database Approach and File
Processing System:Database approach vs. File processing approach:
Consider an organization/enterprise that is organized as a
collection of departments/offices. Each department has certain data
processing "needs", many of which are unique to it. In the file
processing approach, each department would "own" a collection of
relevant data and software applications to manipulate that data.
For example, a university's Registrar's Office would maintain (most
likely, with the aid of programmers employed by the university's
"computer center") data (and programs) relevant to student grades
and course enrollments. The A.O Office would maintain data (and
programs) regarding fees owed by students for tuition, room and
board, etc. One result of this approach is, typically, data
redundancy, which not only wastes storage space but also makes it
more difficult to keep changing data up-to-date, as a change to one
copy of some data item must be made to all of them (called
duplication-of-effort). Inconsistency results when one (or more)
copies of a datum are changed but not others. (E.g., If you change
your address, informing the Department's Office should suffice to
ensure that your grades are sent to the right place, but does not
guarantee that your next bill will be, as the copy of your address
"owned" by the A.Os Office might not have been changed.) Data
Levels and their Roles :
Physical corresponds to the first view of data: How data is
stored, how is it accessed, how data is modified, is data ordered,
how data is allocated to computer memory and/or peripheral devices,
how data items are actually represented (ASCI, EBCDIC,) .The
physical schema speci es additional storage details. Essentially,
the physical schema summarizes how the relations described in the
conceptual schema are actually stored on secondary storage devices
such as disks and tapes. We must decide what le organizations to
use to store the relations, and create auxiliary data structures
called indexes to speed up data retrieval operations. Conceptual
corresponds to the second view of data: What we want the data to
express and what relationships between data we must express, what
story data tells, are all data necessary for the story are
discussed. The conceptual schema (sometimes called the logical
schema) describes the stored data in terms of the data model of the
DBMS. In a relational DBMS, the conceptual schema describes all
relations that are stored in the database. In our sample university
database, these relations contain information about entities, such
as students and faculty, and about relationships, such as students'
enrollment in courses. All student entities can be described using
records in a Students relation, as we saw earlier. In fact, each
collection of entities and each collection of relationships can be
described as a relation, leading to the following conceptual
schema:Students(sid: string, name: string, login: string, age:
integer, gpa: real) Faculty( d: string, fname: string, sal: real)
Courses(cid: string, cname: string, credits: integer) Rooms(rno:
integer, address: string, capacity: integer) Enrolled(sid: string,
cid: string, grade: string) Teaches( d: string, cid: string) Meets
In(cid: string, rno: integer, time: string) The choice of
relations, and the choice of elds for each relation, is not always
obvious, and the process of arriving at a good conceptual schema is
called conceptual database design. View corresponds to the third
view of data:What part of the data is seen by a specific
application .External schemas, which usually are also in terms of
the data model of the DBMS, allow data access to be customized (and
authorized) at the level of individual users or groups of users.
The external schema design is guided by end user requirements. For
example, we might ant to allow students to find out the names of
faculty members teaching courses, as well as course enrollments.
This can be done by defining the following view: Courseinfo(cid:
string, fname: string, enrollment: integer)
STRUCTURE OF A DBMS:
When a user issues a query, the parsed query is presented to a
query optimizer, which uses information about how the data is
stored to produce an effcient execution plan for evaluating the
query. An execution plan is a blueprint for evaluating a query, and
is usually represented as a tree of relational operators. The code
that implements relational operators sits on top of the le and
access methods layer. This layer includes a variety of software for
supporting the concept of a le, which, in a DBMS, is a collection
of pages or a collection of records. This layer typically supports
a heap le, or le of unordered pages, as well as indexes. In
addition to keeping track of the pages in a le, this layer
organizes the information within a page.The les and access methods
layer code sits on top of the buer manager, which brings pages in
from disk to main memory as needed in response to read requests.The
lowest layer of the DBMS software deals with management of space on
disk, where the data is stored. Higher layers allocate, deallocate,
read, and write pages through (routines provided by) this layer,
called the disk space manager. The DBMS supports concurrency and
crash recovery by carefully scheduling user requests and
maintaining a log of all changes to the database. DBMS components
associated with concurrency control and recovery include the
transaction manager, which ensures that transactions request and
release locks according to a suitable locking protocol and
schedules the execution transactions; the lock manager, which keeps
track of requests for locks and grants locks on database objects
when they become available; and the recovery manager, which is
responsible for maintaining a log, and restoring the system to a
consistent state after a crash. The disk space manager, buffer
manager, and le and access method layers must interact with these
components.Database Users:1. Database Administrator (DBA): This is
the chief administrator, who oversees and manages the database
system (including the data and software). Duties include
authorizing users to access the database, coordinating/monitoring
its use, acquiring hardware/software for upgrades, etc. In large
organizations, the DBA might have a support staff. 1. Database
Designers: They are responsible for identifying the data to be
stored and for choosing an appropriate way to organize it. They
also define views for different categories of users. The final
design must be able to support the requirements of all the user
sub-groups. 1. End Users: These are persons who access the database
for querying, updating, and report generation. They are main reason
for database's existence! 2. Casual end users: use database
occasionally, needing different information each time; use query
language to specify their requests; typically middle- or high-level
managers. 2. Naive/Parametric end users: Typically the biggest
group of users; frequently query/update the database using standard
canned transactions that have been carefully programmed and tested
in advance. Examples: 1. bank tellers check account balances, post
withdrawals/deposits 1. Reservation clerks for airlines, hotels,
etc., check availability of seats/rooms and make reservations. 1.
Shipping clerks (e.g., at DTDC) who use buttons, bar code scanners,
etc., to update status of in-transit packages. 2. Sophisticated end
users: engineers, scientists, business analysts who implement their
own applications to meet their complex needs. 2. Stand-alone users:
Use "personal" databases, possibly employing a special-purpose
(e.g., financial) software package. 1. System Analysts, Application
Programmers, Software Engineers: 3. System Analysts: determine
needs of end users, especially naive and parametric users, and
develop specifications for canned transactions that meet these
needs. 3. Application Programmers: Implement, test, document, and
maintain programs that satisfy the specifications mentioned above.
6-Capabilities/Advantages of using DBMS: These are additional
characteristics of dbms.1. Controlling Redundancy: Data redundancy
(such as tends to occur in the "file processing" approach) leads to
wasted storage space, duplication of effort (when multiple copies
of a datum need to be updated), and a higher likelihood of the
introduction of inconsistency. a. On the other hand, redundancy can
be used to improve performance of queries. Indexes, for example,
are entirely redundant, but help the DBMS in processing queries
more quickly. b. A DBMS should provide the capability to
automatically enforce the rule that no inconsistencies are
introduced when data is updated. 2. Restricting Unauthorized
Access: A DBMS should provide a security and authorization
subsystem, which is used for specifying restrictions on user
accounts. Common kinds of restrictions are to allow read-only
access (no updating), or access only to a subset of the data 3.
Providing Persistent Storage for Program Objects: Object-oriented
database systems make it easier for complex runtime objects (e.g.,
lists, trees) to be saved in secondary storage so as to survive
beyond program termination and to be retrievable at a later time.
4. Providing Storage Structures for Efficient Query Processing: The
DBMS maintains indexes (typically in the form of trees and/or hash
tables) that are utilized to improve the execution time of queries
and updates. (The choice of which indexes to create and maintain is
part of physical database design and tuning and is the
responsibility of the DBA. a. The query processing and optimization
module is responsible for choosing an efficient query execution
plan for each query submitted to the system. 5. Providing Backup
and Recovery: The subsystem having this responsibility ensures that
recovery is possible in the case of a system crash during execution
of one or more transactions. 6. Providing Multiple User Interfaces:
For example, query languages for casual users, programming language
interfaces for application programmers, forms and/or command codes
for parametric users, menu-driven interfaces for stand-alone users.
7. Representing Complex Relationships Among Data: A DBMS should
have the capability to represent such relationships and to retrieve
related data quickly. 8. Enforcing Integrity Constraints: Most
database applications are such that the semantics (i.e., meaning)
of the data require that it satisfy certain restrictions in order
to make sense. Perhaps the most fundamental constraint on a data
item is its data type, which specifies the universe of values from
which its value may be drawn. (E.g., a Grade field could be defined
to be of type Grade_Type, which, say, we have defined as including
precisely the values in the set { "A", "A-", "B+", ..., "F" }. a.
Another kind of constraint is referential integrity, which says
that if the database includes an entity that refers to another one,
the latter entity must exist in the database. 9. Permitting
Inference and Actions Via Rules: In a deductive database system,
one may specify declarative rules that allow the database to infer
new data! E.g., Figure out which students are on academic
probation. Such capabilities would take the place of application
programs that would be used to ascertain such information
otherwise. a. Active database systems go one step further by
allowing "active rules" that can be used to initiate actions
automatically. 10. Potential for enforcing standards: this is very
crucial for the success of database applications in large
organizations Standards refer to data item names, display formats,
screens, report structures, meta-data (description of data) etc.11.
Reduced application development time: incremental time to add each
new application is reduced.12. Flexibility to change data
structures: database structure may evolve as new requirements are
defined.13. Availability of up-to-date information very important
for on-line transaction systems such as airline, hotel, car
reservations.14. Economies of scale: by consolidating data and
applications across departments wasteful overlap of resources and
personnel can be avoided.Database System concepts and
Architecture:1-Data Models, Schemas, and Instances:One fundamental
characteristic of the database approach is that it provides some
level of data abstraction by hiding details of data storage that
are irrelevant to database users. A data model: A set of concepts
to describe the structure of a database, the operations for
manipulating these structures, and certain constraints that the
database should obey.By structure is meant the data types,
relationships, and constraints that should hold for the data. Most
data models also include a set of basic operations for specifying
retrievals/updates. Data Model Building Blocks:Entity 1. Anything
about which data are to be collected and stored2. It is a thing in
real world with an independent existance Attribute 1. A
characteristic of an entity (e.g. last name) 2. It is a Perticular
property that describes the entityRelationship an association among
(two or more) entities 1. One-to-many (1:M) relationship 1.
Many-to-many (M:N or M:M) relationship 1. One-to-one (1:1)
relationship The Evolution of Data Models1. Hierarchical 1. Network
1. Relational 1. Entity relationship 1. Object oriented
Object-oriented data models include the idea of objects having
behavior (i.e., applicable methods) being stored in the database
(as opposed to purely "passive" data). According to C.J. Date (one
of the leading database experts), a data model is an abstract,
self-contained, logical definition of the objects, operators, and
so forth, that together constitute the abstract machine with which
users interact. The objects allow us to model the structure of
data; the operators allow us to model its behavior. In the
relational data model, data is viewed as being organized in
two-dimensional tables comprised of tuples of attribute values.
This model has operations such as Project, Select, and Join. A data
model is not to be confused with its implementation, which is a
physical realization on a real machine of the components of the
abstract machine that together constitute that model. Logical vs.
physical!! 1. There are other well-known data models that have been
the basis for database systems. The best-known models pre-dating
the relational model are the hierarchical (in which the entity
types form a tree) and the network (in which the entity types and
relationships between entities)Categories Of Data Models (Based On
Degree Of Abstractness): 1. High-Level/Conceptual: (e.g., ER model
) provides a view close to the way users would perceive data; uses
concepts such as 0. entity: real-world object or concept (e.g.,
student, employee, course, department, event) 0. attribute: some
property of interest describing an entity (e.g., height, age,
color) 0. relationship: an interaction among entities (e.g.,
works-on relationship between an employee and a project) 1.
Representational/Implementational: intermediate level of
abstractness; example is relational data model (or network). Also
called record-based model. 1. Low-Level/Physical: gives details as
to how data is stored in computer system, such as record formats,
orderings of records, access paths (indexes). Schemas, Instances,
and Database State One must distinguish between the description of
a database and the database itself. The former is called the
database schema, which is specified during design and is not
expected to change often. The actual data stored in the database
probably changes often. The data in the database at a particular
time is called the state of the database, or a snapshot. Schema is
also called intension. State is also called
extension.2-Three-Schema Architecture: This idea was first
described by the ANSI/SPARC committee in late 1970's. The goal is
to separate (i.e., insert layers of "insulation" between) user
applications and the physical database. It is an ideal that few
real-life DBMS's achieve fully. 1. Internal/Physical Schema:
describes the physical storage structure (using a low-level data
model) 1. Conceptual Schema: describes the (logical) structure of
the whole database for a community of users. Hides physical storage
details, concentrating upon describing entities, data types,
relationships, user operations, and constraints. Can be described
using either high-level or implementational data model. 1. External
Schema (or user views): Each such schema describes part of the
database that a particular category of users is interested in,
hiding rest of database. Can be described using either high-level
or implementational data model. (In practice, usually described
using same model as is the conceptual schema.) Users (including
application programs) submit queries that are expressed with
respect to the external level. It is the responsibility of the DBMS
to transform such a query into one that is expressed with respect
to the internal level (and to transform the result, which is at the
internal level, into its equivalent at the external level).
Example: Select students with GPA > 3.5. Q: How is this
accomplished?A: By virtue of mappings between the levels: 1.
external/conceptual mapping (providing logical data independence)
1. conceptual/internal mapping (providing physical data
independence) Data independence is the capacity to change the
schema at one level of the architecture without having to change
the schema at the next higher level. We distinguish between logical
and physical data independence according to which two adjacent
levels are involved. The former refers to the ability to change the
conceptual schema without changing the external schema. The latter
refers to the ability to change the internal schema without having
to change the conceptual. Logical Data Independence: The capacity
to change the conceptual schema without having to change the
external schemas and their associated application programs.Physical
Data Independence:The capacity to change the internal schema
without having to change the conceptual schema.For an example of
physical data independence, suppose that the internal schema is
modified (because we decide to add a new index, or change the
encoding scheme used in representing some field's value, or
stipulate that some previously unordered file must be ordered by a
particular field ). Then we can change the mapping between the
conceptual and internal schemas in order to avoid changing the
conceptual schema itself. Not surprisingly, the process of
transforming data via mappings can be costly (performance-wise),
which is probably one reason that real-life DBMS's don't fully
implement this 3-schema architecture. 3-DBMS Languages :DDL: Data
definition (conceptual schema, possibly internal/external) language
Used by the DBA and database designers to specify the conceptual
schema of a database. In many DBMSs, the DDL is also used to define
internal and external schemas (views). In some DBMSs, separate
storage definition language (SDL) and view definition language
(VDL) are used to define internal and external schemas.SDL: Storage
definition (internal schema) language SDL is typically realized via
DBMS commands provided to the DBA and database designersVDL: View
definition (external schema) languageDML: Data manipulation
(retrieval, update) language High-Level or Non-procedural
Languages: These include the relational language SQL May be used in
a standalone way or may be embedded in a programming language Low
Level or Procedural Languages: These must be embedded in a
programming language
Entity-Relationship ModelEntity-Relationship (ER) Model:Our
focus now is on the second phase, conceptual design, for which The
Entity-Relationship (ER) Model is a popular high-level conceptual
data model. In the ER model, the main concepts are entity,
attribute, and relationship. Entities and AttributesEntity: An
entity represents some "thing" (in the miniworld) that is of
interest to us, i.e., about which we want to maintain some data. An
entity could represent a physical object (e.g., house, person,
automobile, widget) or a less tangible concept (e.g., company, job,
academic course). Attribute: An entity is described by its
attributes, which are properties characterizing it. Each attribute
has a value drawn from some domain (set of meaningful values).
Example: A STUDENT entity might be described by RNO, Name,
BirthDate, etc., attributes, each having a particular value. What
distinguishes an entity from an attribute is that the latter is
strictly for the purpose of describing the former and is not, in
and of itself, of interest to us. It is sometimes said that an
entity has an independent existence, whereas an attribute does not.
In performing data modeling, however, it is not always clear
whether a particular concept deserves to be classified as an entity
or "only" as an attribute. We can classify attributes along these
dimensions: 1. simple/atomic vs. composite 1. single-valued vs.
multi-valued (or set-valued) 1. stored vs. derived A composite
attribute is one that is composed of smaller parts. An atomic
attribute is indivisible or indecomposable.A simple/atomic
attributes that are not divisible1. Example 1: A BirthDate
attribute can be viewed as being composed of (sub-)attributes for
month, day, and year. 1. Example 2: An Address attribute can be
viewed as being composed of (sub-)attributes for street address,
city, state, and zip code. A street address can itself be viewed as
being composed of a number, street name, and apartment number. As
this suggests, composition can extend to a depth of two (as here)
or more. To describe the structure of a composite attribute, one
can draw a tree , it is customary to write its name followed by a
parenthesized list of its sub-attributes. For the examples
mentioned above, we would write
BirthDate(Month,Day,Year)Address(StreetAddr(StrNum, StrName,
AptNum), City, State, Zip)
Single- vs. multi-valuedSingle valued: Most of attributes have
single value for particulary entity.Multi valued: Attrbute can have
set of values for some entitiesattribute: Consider a PERSON entity.
The person it represents has (one) SSN, (one) date of birth, (one,
although composite) name, etc. But that person may have zero or
more academic degrees, dependents, or (if the person is a male
living in tenali) spouses! How can we model this via attributes
AcademicDegrees, Dependents, and Spouses? One way is to allow such
attributes to be multi-valued , which is to say that we assign to
them a (possibly empty) set of values rather than a single value.
To distinguish a multi-valued attribute from a single-valued one,
it is customary to enclose the former within curly braces (which
makes sense, as such an attribute has a value that is a set, and
curly braces are traditionally used to denote sets). Using the
PERSON example from above, we would depict its structure in text as
PERSON(SSN, Name, BirthDate(Month, Day, Year), {
AcademicDegrees(School, Level, Year) }, { Dependents }, ...) Here
we have taken the liberty to assume that each academic degree is
described by a school, level (e.g., B.S., Ph.D.), and year. Thus,
AcademicDegrees is not only multi-valued but also composite. We
refer to an attribute that involves some combination of
multi-valuedness and compositeness as a complex attribute. A more
complicated example of a complex attribute is AddressPhone. This
attribute is for recording data regarding addresses and phone
numbers of a business. The structure of this attribute allows for
the business to have several offices, each described by an address
and a set of phone numbers that ring into that office. Its
structure is given by { AddressPhone( { Phone(AreaCode, Number) },
Address(StrAddr(StrNum, StrName, AptNum), City, State, Zip)) }
Stored vs. derived attribute: Perhaps independent and derivable
would be better terms for these (or non-redundant and redundant).
In any case, a derived attribute is one whose value can be
calculated from the values of other attributes, and hence need not
be stored. Example: Age can be calculated from BirthDate, assuming
that the current date is accessible. BirthDate attribute is called
stored attributesThe Null value: In some cases a particular entity
might not have an applicable value for a particular attribute. Or
that value may be unknown. Or, in the case of a multi-valued
attribute, the appropriate value might be the empty set. Example:
The attribute DateOfDeath is not applicable to a living person and
its correct value may be unknown for some persons who have died. In
such cases, we use a special attribute value, called null. There
has been some argument in the database literature about whether a
different approach (such as having distinct values for not
applicable and unknown) would be superior. 3-Entity Types, Entity
Sets, Keys, and DomainsAbove we mentioned the concept of a PERSON
entity, i.e., a representation of a particular person via the use
of attributes such as Name, Sex, etc. Chances are good that, in a
database in which one such entity exists, we will want many others
of the same kind to exist also, each of them described by the same
collection of attributes. Of course, the values of those attributes
will differ from one entity to another (e.g., one person will have
the name "keerthy" and another will have the name "sai"). Just as
likely is that we will want our database to store information about
other kinds of entities, such as business transactions or academic
courses, which (of course) will be described by entirely different
collections of attributes. This illustrates the distinction between
entity types and entity instances. An entity type serves as a
template for a collection of entity instances, all of which are
described by the same collection of attributes. That is, an entity
type is analogous to a class in object-oriented programming and an
entity instance is analogous to a particular object (i.e., instance
of a class). In ER modeling, we deal only with entity types, not
with instances or occurrences. In an ER diagram, each entity type
is denoted by a rectangular box. An entity set is the collection of
all entities of a particular type that exist, in a database, at
some moment in time. Relationship Sets:A relationship is an
association among several entities. A relationship set is a set of
relationships of the same type.Mapping Cardinalities:Mapping
cardinalities, or cardinality ratios, express the number of
entities to which another entity can be associated via a
relationship set. Mapping cardinalities are most useful in
describing binary relationship sets, although they can contribute
to the description of relationship sets that involve more than two
entity sets. One to one. An entity in A is associated with at most
one entity in B, and an entity in B is associated with at most one
entity in A. One to many. An entity in A is associated with any
number (zero or more) of entities in B. An entity in B, however,
can be associated with at most one entity in A. Many to one. An
entity in A is associated with at most one entity in B. An entity
in B, however, can be associated with any number (zero or more) of
entities in A. Many to many. An entity in A is associated with any
number (zero or more) of entities in B, and an entity in B is
associated with any number (zero or more) of entities in A.Keys: A
key allows us to identify a set of attributes that suffice to
distinguish entities from each other. Keys also help uniquely
identify relationships, and thus distinguish relationships from
each other.superkey:A superkey is a set of one or more attributes
that, taken collectively, allow us to identify uniquely an entity
in the entity set. For example, the customer-id attribute of the
entity set customer is sufficient to distinguish one customer
entity from another. Thus, customer-id is a superkey. Similarly,
the combination of customer-name and customer-id is a superkey for
the entity set customer. The customer-name attribute of customer is
not a superkey, because several people might have the same
name.candidate key:minimal superkeys are called candidate keys.If K
is a superkey, then so is any superset of K. We are often
interested in superkeys for which no proper subset is a superkey.It
is possible that several distinct sets of attributes could serve as
a candidate key.Suppose that a combination of customer-name and
customer-street is sufficient to distinguish among members of the
customer entity set. Then, both {customer-id} and {customer-name,
customer-street} are candidate keys. Although the attributes
customerid and customer-name together can distinguish customer
entities, their combination does not form a candidate key, since
the attribute customer-id alone is a candidate key.primary
key:which denotes the unique identity is called as primary
key.primary key to denote a candidate key that is chosen by the
database designer as the principal means of identifying entities
within an entity set. A key (primary, candidate, and super) is a
property of the entity set, rather than of the individual entities.
Any two individual entities in the set are prohibited from having
the same value on the key attributes at the same time. The
designation of a key represents a constraint in the real-world
enterprise being modeled.Weak Entity Sets:An entity set may not
have sufficient attributes to form a primary key. Such an entity
set is termed a weak entity set. An entity set that has a primary
key is termed a strong entity set.Constraints on Relationship
Types:Often, in order to make a relationship type be an accurate
model of the miniworld concepts that it is intended to represent,
we impose certain constraints that limit the possible corresponding
relationship sets. (That is, a constraint may make "invalid" a
particular set of instances for a relationship type.) There are two
main kinds of relationship constraints (on binary relationships).
For illustration, let R be a relationship set consisting of ordered
pairs of instances of entity types A and B, respectively. 1.
Cardinality Ratio: 0. 1:1 (one-to-one): Under this constraint, no
instance of A may particpate in more than one instance of R;
similarly for instances of B. In other words, if (a1, b1) and (a2,
b2) are (distinct) instances of R, then neither a1 = a2 nor b1=b2.
Example: Our informal description of COMPANY says that every
department has one employee who manages it. If we also stipulate
that an employee may not (simultaneously) play the role of manager
for more than one department, it follows that MANAGES is 1:1. 0.
1:N (one-to-many): Under this constraint, no instance of B may
participate in more than one instance of R, but instances of A are
under no such restriction. In other words, if (a1, b1) and (a2, b2)
are (distinct) instances of R, then it cannot be the case that b1 =
b2. Example: CONTROLS is 1:N because no project may be controlled
by more than one department. On the other hand, a department may
control any number of projects, so there is no restriction on the
number of relationship instances in which a particular department
instance may participate. For similar reasons, SUPERVISES is also
1:N. 0. N:1 (many-to-one): This is just the same as 1:N but with
roles of the two entity types reversed. Example: WORKS_FOR and
DEPENDS_ON are N:1. 0. M:N (many-to-many): Under this constraint,
there are no restrictions. (Hence, the term applies to the absence
of a constraint!) Example: WORKS_ON is M:N, because an employee may
work on any number of projects and a project may have any number of
employees who work on it. Introduction toSQLSQL is a standard
language for accessing and manipulating databases. SQL stands for
Structured Query Language SQL lets you access and manipulate
databases SQL is an ANSI (American National Standards Institute)
standard SQL Features SQL can execute queries against a database
SQL can retrieve data from a database SQL can insert records in a
database SQL can update records in a database SQL can delete
records from a database SQL can create new databases SQL can create
new tables in a database SQL can create stored procedures in a
database SQL can create views in a database SQL can set permissions
on tables, procedures, and viewsAlthough SQL is an ANSI (American
National Standards Institute) standard, there are many different
versions of the SQL language. However, to be compliant with the
ANSI standard, they all support at least the major commands (such
as SELECT, UPDATE, DELETE, INSERT, WHERE) in a similar manner.Using
SQL in Your Web SiteTo build a web site that shows some data from a
database, you will need the following: An RDBMS database program
(i.e. MS Access, SQL Server, MySQL) A server-side scripting
language, like PHP or ASP SQL HTML / CSSRDBMSRDBMS stands for
Relational Database Management System. RDBMS is the basis for SQL,
and for all modern database systems like MS SQL Server, IBM DB2,
Oracle, MySQL, and Microsoft Access. The data in RDBMS is stored in
database objects called tables. A table is a collections of related
data entries and it consists of columns and rows.SQLSyntaxDatabase
TablesA database most often contains one or more tables. Each table
is identified by a name (e.g. "Customers" or "Orders"). Tables
contain records (rows) with data.SQL StatementsMost of the actions
you need to perform on a database are done with SQL statements. The
following SQL statement will select all the records in the
table:SELECT * FROM Table-NameSome database systems require a
semicolon at the end of each SQL statement. Semicolon is the
standard way to separate each SQL statement in database systems
that allow more than one SQL statement to be executed in the same
call to the server.SQL DML and DDLSQL can be divided into two
parts: The Data Manipulation Language (DML) and the Data Definition
Language (DDL). The query and update commands form the DML part of
SQL: SELECT- extracts data from a database UPDATE- updates data in
a database DELETE- deletes data from a database INSERT INTO-
inserts new data into a databaseThe DDL part of SQL permits
database tables to be created or deleted. It also define indexes
(keys), specify links between tables, and impose constraints
between tables. The most important DDL statements in SQL are:
CREATE DATABASE- creates a new database ALTER DATABASE- modifies a
database CREATE TABLE- creates a new table ALTER TABLE- modifies a
table DROP TABLE- deletes a table CREATE INDEX- creates an index
(search key) DROP INDEX- deletes an indexSQLSELECTStatementThe SQL
SELECT StatementThe SELECT statement is used to select data from a
database. The result is stored in a result table, called the
result-set.SQL SELECT SyntaxSELECT column_name(s)FROM
table_nameAndSELECT * FROM table_nameSQLSELECT DISTINCTStatementThe
SQL SELECT DISTINCT StatementIn a table, some of the columns may
contain duplicate values. This is not a problem, however, sometimes
you will want to list only the different (distinct) values in a
table. The DISTINCT keyword can be used to return only distinct
(different) values.SQL SELECT DISTINCT SyntaxSELECT DISTINCT
column_name(s)FROM table_nameSQLWHEREClauseThe WHERE clause is used
to extract only those records that fulfill a specified
criterion.SQL WHERE SyntaxSELECT column_name(s)FROM table_nameWHERE
column_name operator valueQuotes Around Text FieldsSQL uses single
quotes around text values (most database systems will also accept
double quotes). Although, numeric values should not be enclosed in
quotes.For text values: SELECT * FROM Persons WHERE
FirstName='Tove'
For numeric values: SELECT * FROM Persons WHERE Year=1965
Operators Allowed in the WHERE ClauseWith the WHERE clause, the
following operators can be used:OperatorDescription
=Equal
Not equal
>Greater than
=Greater than or equal
