Department of Computer Science & Engineering Question Bank Unit I Introduction and Conceptual Modelling PART-A (2 Marks)
Department of Computer Science & Engineering Question Bank Unit I Introduction and Conceptual Modelling PART-A (2 Marks)
Department of Computer Science & Engineering Question Bank Unit I Introduction and Conceptual Modelling PART-A (2 Marks)
COLLEGE OF ENGINEERING
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.
Efficient data access: A DBMS utilizes a variety of sophisticated techniques to store and retrieve data eficiently. 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 can offer significant
improvements. Experienced professionals who understand the nature of the data being managed, and how di
erent groups of users use it, can be responsible for organizing the data representation to minimize redundancy and for
retuning the storage of the data to make retrieval efficient.
Concurrent access and crash recovery: A DBMS schedules concurrent accesses to the data in such a manner that
users can think of the data as being accessed by only one user at a time. Further, the DBMS protects users from the
effects of system failures.
Reduced application development time: Clearly, the DBMS supports many important functions that are common to
many applications accessing data stored in the DBMS. This, in conjunction with the high-level interface to the data,
facilitates quick development of applications. Such applications are also likely to be more robust than applications
developed from scratch because many important tasks are handled by the DBMS instead of being implemented by the
application.
Given all these advantages, is there ever a reason not to use a DBMS? A DBMS is a complex piece of software,
optimized for certain kinds of workloads (e.g., answering complex queries or handling many concurrent requests), and
its performance may not be adequate for certain specialized applications. Examples include applications with tight
real-time constraints or applications with just a few well-defined critical operations for which eficient custom code
must be written. Another reason for not using a DBMS is that an application may need to manipulate the data in ways
not supported by the query language. In such a situation, the abstract view of the data presented by the DBMS does not
match the application’s needs, and actually gets in the way. As an example, relational databases do not support flexible
analysis of text data (although vendors are now extending their products in this direction). If specialized performance
or data manipulation requirements are central to an application, the application may choose not to use a DBMS,
especially if the added benefits’ of a DBMS (e.g., flexible querying, security, concurrent access, and crash recovery)
are not required. In most situations calling for large-scale data management, however, DBMSs have become an
indispensable tool.
The first stage of information system design uses these models during the requirements analysis to describe
information needs or the type of information that is to be stored in a database. The data modeling technique can be
used to describe any ontology(i.e. an overview and classifications of used terms and their relationships) for a
certain area of interest. In the case of the design of an information system that is based on a database, the conceptual
data model is, at a later stage (usually called logical design), mapped to a logical data model, such as the relational
model; this in turn is mapped to a physical model during physical design. Note that sometimes, both of these phases
are referred to as "physical design".
There are a number of conventions for entity-relationship diagrams (ERDs). The classical notation mainly relates
to conceptual modeling. There are a range of notations employed in logical and physical database design, such
as IDEF1X.
An entity may be defined as a thing which is recognized as being capable of an independent existence and which can
be uniquely identified. An entity is an abstraction from the complexities of some domain. When we speak of an entity
we normally speak of some aspect of the real world which can be distinguished from other aspects of the real world.[3]
An entity may be a physical object such as a house or a car, an event such as a house sale or a car service, or a concept
such as a customer transaction or order. Although the term entity is the one most commonly used, following Chen we
should really distinguish between an entity and an entity-type. An entity-type is a category. An entity, strictly
speaking, is an instance of a given entity-type. There are usually many instances of an entity-type. Because the term
entity-type is somewhat cumbersome, most people tend to use the term entity as a synonym for this term.
Entities can be thought of as nouns. Examples: a computer, an employee, a song, a mathematical theorem. Entities are
represented as rectangles.
A relationship captures how two or more entities are related to one another. Relationships can be thought of as verbs,
linking two or more nouns. Examples: an owns relationship between a company and a computer, a
supervises relationship between an employee and a department, a performs relationship between an artist and a song,
a proved relationship between a mathematician and a theorem. Relationships are represented as diamonds, connected
by lines to each of the entities in the relationship.
The model's linguistic aspect described above is utilized in the database query language ERROL.
Entities and relationships can both have attributes. Examples: an employee entity might have a Social Security
Number (SSN) attribute; the proved relationship may have a date attribute. Attributes are represented as ellipses
connected to their owning entity sets by a line.
Every entity (unless it is a weak entity) must have a minimal set of uniquely identifying attributes, which is called the
entity'sprimary key.
Entity-relationship diagrams don't show single entities or single instances of relations. Rather, they show entity sets
and relationship sets. Example: a particular song is an entity. The collection of all songs in a database is an entity set.
The eatenrelationship between a child and her lunch is a single relationship. The set of all such child-lunch
relationships in a database is a relationship set. In other words, a relationship set corresponds to a relation in
mathematics, while a relationship corresponds to a member of the relation.