Professional Documents
Culture Documents
Untitled
Untitled
MODULE
This module deals with the basic concepts of data management systems.
2. INTRODUCTION
This module explains the various data languages. Then it deals with the definition of database
views. The benefits of database views are explained. Then the data models are explained in detail.
3. LEARNING OUTCOME
The outcome of this module is to explain the basic concepts of database management systems and
clarify the misconceptions about the various topics in the subject.
4. LANGUAGES
The languages involved in database management systems are
(i) Data Definition Language
(ii) Data Manipulation Language
(iii) Data Control Language
Answer : True.
Explanation : Procedural DML describes how the manipulation is to be done.
5. DATABASE VIEWS
The following unit deals with the database views.
5.1 VIEWS
Allows each user to have his or her own view of the database.
A view is essentially some subset of the database.
5.2 BENEFITS
Reduce complexity
Provide a level of security
Provide a mechanism to customize the appearance of the database
Present a consistent, unchanging picture of the structure of the database, even if the underlying
database is changed.
6. COMPONENTS OF DBMS
DATA
HARDWARE SOFTWARE HARDWARE SOFTWARE
Hardware : can range from a PC to a network of computers.
Software : DBMS, operating system, network software (if necessary) and also the application
programs.
Data - used by the organization and a description of this data called the schema.
Procedures - instructions and rules that should be applied to the design and use of the database and
DBMS.
7. ROLES
Data Administrator(DA)
Database Administrator(DBA) – where exactly to store
Database Designers(Logical and Physical) – structure of the database
Application Programmers – merge the differences between the exggternal and internal level
End users(naive and sophisticated) – never exposed to this kind of system, to who know the query
language.
8. DATABASE MODELS
We have to talk about the evolution of database.
INTEGRATION
FEDERATION
EXTENSIBILITY
DISTRIBUTION
OPTIMIZATION
DATA INDEPENDANCE
Answer : False.
Explanation : Object based, record based, physical are some of the categories of data model.
A relational database is based on the relational model developed by E.F. Codd. A relational database
allows the definition of data structures, storage and retrieval operations and integrity constraints. In
such a database the data and relations between them are organized into tables. A table is a collection
of records and each record in a table contains the same fields. The contents of a table can be
permanently saved for future use.
Properties of the relational database model
Properties of Relational Tables:
1. Data is presented as a collection of relations.
2. Each relation is depicted as a table.
3. Columns are attributes that belong to the entity modeled by the table (ex. In a student table, you
could have name, address, student ID, major, etc.).
4. Each row ("tuple") represents a single entity (ex. In a student table, John Smith, 14 Oak St,
9002342, Accounting, would represent one student entity).
5. Every table has a set of attributes that taken together as a "key" (technically, a "superkey")
uniquely identifies each entity (Ex. In the student table, ―student ID‖ would uniquely identify each
student – no two students would have the same student ID).
Overview
Certain fields may be designated as keys, which means that searches for specific values of that field
will use indexing to speed them up and more importantly, uniquely identify each entity. There are
many types of keys, however, quite possibly the two most important are the primary key and the
foreign key. The primary key is what uniquely identifies each entity. The foreign key is a primary
key of one table that also sits in another table. Ultimately, the use of foreign keys is the heart of the
relational database model. This linkage that the foreign key provides is what allows tables to pull
data from each other and link data together. Where fields in two different tables take values from
the same set, a join operation can be performed to select related records in the two tables by
matching values in those fields. Most often, but not always, the fields will have the same name in
both tables. For example, an "orders" table might contain (customer-ID – primary key, product-code
– foreign key) pairs and a "products" table might contain (product-code – primary key, price) pairs
so to calculate a given customer's bill you would sum the prices of all products ordered by that
customer by joining on the product-code fields of the two tables. This can be extended to joining
multiple tables on multiple fields. Because these relationships are only specified at retrieval time,
relational databases are classed as dynamic database management system.
According to Rao (1994), "The object-oriented database (OODB) paradigm is the combination of
object-oriented programming language (OOPL) systems and persistent systems. The power of the
OODB comes from the seamless treatment of both persistent data, as found in databases, and
transient data, as found in executing programs."
In contrast to a relational DBMS where a complex data structure must be flattened out to fit into
tables or joined together from those tables to form the in-memory structure, object DBMSs have no
performance overhead to store or retrieve a web or hierarchy of interrelated objects. This one-to-one
mapping of object programming language objects to database objects has two benefits over other
storage approaches: it provides higher performance management of objects, and it enables better
management of the complex interrelationships between objects. This makes object DBMSs better
suited to support applications such as financial portfolio risk analysis systems, telecommunications
service applications, world wide web document structures, design and manufacturing systems, and
hospital patient record systems, which have complex relationships between data.
Semistructured data has recently emerged as an important topic of study for a variety of reasons.
First, there are data sources such as the Web, which we would like to treat as databases but which
cannot be constrained by a schema. Second, it may be desirable to have an extremely flexible
format for data exchange between disparate databases. Third, even when dealing with structured
data, it may be helpful to view it as semistructured for the purposes of browsing.
8.1.7 ER DIAGRAM
An Entity Relationship Diagram (ERD) is a data model describing how entities (or concepts or
things) relate to one another. When created by business analysts, ERDs can be used to understand
the business domain, clarify business terminology, and connect business concepts to database
structures.
Essentially, a conceptual or logical ERD will visually show how the terms in your glossary relate to
one another. They are especially helpful in clarifying information models for relational databases
and helping business users understand database structures at a high level and without details.
Relationships – The real insight from this type of diagram comes when we see how entities
relate to one another, or relationships. Relationships can be thought of as verbs that link two
or more nouns. Relationships can be modeled numerically, using the multiplicity syntax
from a class diagram, or using Crows Foot Notation.
Attributes – Within each entity, there can be more than one attribute. Attributes provide
detailed information about the concept. In a relational database, attributes are represented by
the fields where the information inside a record is held.
Like any analysis model, creating an ERD is an iterative process that involves elicitation, analysis,
and review with stakeholders. Here are some steps you’ll go through as you create an ERD.
1. Create boxes for each entity or primary business concept relevant to your model.
2. Model the relationships between each by drawing lines to connect related entities. Label the
relationships using verbs or a numeric notation. Crows Foot Notation is common for ERDs,
but you can also use the multiplicity notation from UML’s Class Diagrams.
3. Identify relevant attributes within each entity. For a conceptual model, focus on the most
important attributes. As your model evolves, make your attribute lists more specific.
4. Review your model with business and technical stakeholders.
5. Repeat until your domain is well-represented by your model.
As an end result, you’ll have clearly defined how different business concepts relate to one another,
and created a solid conceptual foundation for designing a relational database to support your
business requirements, as well as a way to get business and technical stakeholders on the same page
about how these concepts relate.
9. ADVANTAGES OF DBMS
Balance conflicting requirements
Improved data accessibility and reponsiveness
Increased productivity
Improved maintenance through data independance
Increased concurrency
Improved backup and recovery services.
10. SUMMARY
This session we have dealt with the introduction to database management systems.
We have also discussed about the roles and components of database management system.
The various information models have been discussed. We have listed the advantages of DBMS.