Scroll Down to download Lecture in PDF
Scroll down to download Lecture in PDFLecture No. 06
Database Management System
(CS-104)
Lecture No. 06
Overview of Lecture
o Detailed DFD Diagrams:
o Database Design Phase
o Data Models
o Types of Data Models
o Types of Database Designs
Detailed Data Flow Diagram:
This Type of the Data flow diagrams is used when we have to further explain
the functionality of the processes that we showed briefly in the Level 0
Diagram. It means that generally detailed DFDS are expressed as the
successive details of those processes for which we do not or could not provide
enough details.
The symbols and other rules regarding the detailed DFD are same as are in
other types of DFDs. The special features associated with this diagram are that,
one, it is optional, that is, it is created for only those processes from the level
0 diagram for which we want to show the details. For a small sized system, we
may not need to develop even a single detailed DFD, since the level 0 diagram
might be covering it sufficiently. Second specific characteristic of the detailed
DFD is its processes’ numbering. Numbering of processes in the detailed DFD
is done on the basis of numbering of the particular process in level 0 diagrams
whose sub-processes are being included in the detailed DFD. For example, a
specific process which was numbered in the level 0 diagram as 1.0 or 1 may
have a number of sub-processes since we did not represent the process 1.0 in
detail in level 0 diagrams. So, in the detailed dataflow diagram we create subprocesses of that process and then number all the sub processes of that specific
process as the sublets of the process.
Numbering of such sub processes is done as 1.1, 1.2, and 1.3… for first second
and third sub-processes of the process 1.0 respectively. The phenomenon of creating sub-processes does not end at creating a few sub-processes for a
specific process shown at level 0 diagrams. Rather it may continue deeper if
there is requirement for further explanation of the any process or sub-
processes. In such a case when we create sub-process of a sub- process 1.2
then the numbering is done in further extension of that specific sub processes
number and example of such a numbering process is 1.2.1, 1.2.2, 1.2.3,…
Another point that is worth mentioning here is that we call processes in the
detailed DFDs as sub-processes, but they are sub-processes only in reference
to the process whose details they are explaining otherwise they are just like
processes; transforming some input data into some form of output. The subprocesses may be performing relatively small amount of operations, still they
are processes. Maximum Number of Process in a DFD should not be very huge. Having a
moderate number for a detailed DFD is also recommended because it adds
clarity to our detailed data flow diagram. For clarity propose it is good to have
a maximum of 7 or 9 processes in one detailed DFD. Moreover, all the
processes, sub processes, data stores, entities data flows and all other
components of the DFD must be named properly, so that anyone who is using
this DFD should be able to understand the DFD easily.
In all the levels of DFD it must be considered that all the processes have data
inputs as well as data outputs. Data being sent to one process should be
processed so that it changes its form and transforms from one form to another.
When creating a detailed diagram, the data inputs and data outputs must be in
coincidence, mean in both the diagrams the data input to a process and data
output in the form of data flows must be same.
Data Dictionary
A database that containing data about all the databases in the database system.
Data dictionaries store all the various schema and file specifications and their
locations. They also contain information about which programs use which
data and which users are interested in which reports.
Types of Data Dictionaries:
o Integrated
There are basically two types of data dictionaries which are available for use
by a DBMS, with respect to their existence.
The first type of data dictionary in this context is the integrated data
dictionary. Such a data dictionary is place embedded into the database system,
and is created by the DBMS for its usage under the directions and
requirements provided by the DBA
As the DBMS needs to talk with the “three level architecture” of database and
mapping information along with all the database design information lies in the
database schema. The DBMS uses the data dictionary to access the database
at each layer or model, for this purpose the data dictionary of any type can be used but the integrated data dictionary is far more efficient than any free
standing data dictionary because an integrated data dictionary is created by
the DBMS itself and uses the same data accessing techniques etc. o Free Standing Second type of data dictionary is free standing data dictionary create by any CASE tool and then attached to the database management systems. A number of case tools are available for this purpose and help user designing the database and the database applications as well in some modern forms of the CASE tools. Database Design Phase Database design phase follows the analysis phase. Before starting the discussion on the design activity, it will be wise if we clearly understand some basic concepts that are frequently used in this phase. o Database Design /Database Model These terms can be used interchangeably for the logical structure of the database. The database design/model stores the structure of the data and the links/relationships between data that should be stored to meet the users’ requirements. Database design is stored in the database schema, which is in turn stored in the data dictionary. o Database Modeling The process of creating the logical structure of the database is called database modeling. It is a very important process because the designing of the application provides us the basis for running our database system. If the database is not designed properly the implementation of the system cannot be done properly. Generally, the design of the database is represented graphically because it provides an ease in design and adds flexibility for the understanding of the system easily. Data Model Data model is a set or collection of constructs used for creating a database and producing designs for the databases. There are a few components of a data model: o Structure: What structures can be used to store the data is identified by the structures provided by the data model structures. o Manipulation Language For using a certain model certain data manipulation are performed using a specific language. This specific language is called data manipulation language. o Integrity Constraints These are the rules which ensure the correctness of data in the database and maintain the database in usable state so that correct information is portrayed in designing the database. Generally, these components are not explicitly defined in data models, they may be available in some of the modern DBMSs but in traditional and general model, these may not be available. Significance of the Data Model Data model is very important tool because it is something which is sued for designing the database for a DBMS and no DBMS can exist independent of any data model, now if we use a specific DBMS but are not sure about the data model it uses for data base usage, we cannot create a proper database. As a specific DBMS is based on the use of a specific data model so when using a DBMS it is of great use to know that what structures, manipulation languages and integrity constraints are implemented by a specific DBMS. As it is the only way to know the facilities and functionalities offered by the DBMS. This is the reason whenever we get a specific DBMS, it is explicitly mentioned with that DBMS, that which data model this DBMS uses. Types of Data Models o Semantic Data Model These are the data models which provide us better flexibility in implementing constraints, better language utilities and better data structure constructs. As a result, actions performed using proper data and structure tools gives us better data designing and manipulation facilities. A better data model provides better opportunities to express multiple situations in the database design and as a result get better output from the tool or model in the form of a better database design. ER- Data Model Object oriented data model Record Based Data Model This is the second type of data models available to use and has three basic types Hierarchical Data Model Network Data model Relational Data model These models are records based and are not in similarity with those of semantic data models. These models handle the data at almost all the three level of the three layers of the database architecture. Semantic data models are generally used for designing the logical or conceptual model of the database system, once very common example of the semantic data model is ER-Data Model and is very much popular for designing databases. No DBMS is based on ER Data model because it is purely used for designing whereas a number of DBMS are available based on OO data model, network data model, relational data model l and hierarchical data model. Types of Database Design Conceptual database design This design is implemented using a semantic data model, for example for creating a design for an organization database we can use and we do use the ER-Data model. Logical Database design This design is performed using a data model for which we have a DBMS available and we are planning to run our database system that DBMS. Physical Database Design: The Logical design created using a specific data model and created after the analysis of the organization, it needs to be implemented in a physical DBMS software so the Physical database design is performed and the design created so far in the logical form are implemented on that very DBMS. By separating the three design levels we get the benefit of abstraction on one hand whereas on the other hand we can create our logical and conceptual designs using better design tools, which would have not been possible if we are using the same design-tool for all the three levels. Moreover, if in future there is a need to make a change in the physical implementation of the data we will have to make no changes in the logical or conceptual level of the database design, rather the change can be achieved by only using the existing conceptual model and implementing it again on Physical model using a separate DBMS.