Documente Academic
Documente Profesional
Documente Cultură
Logical modeling deals with gathering business requirements and converting those requirements into a
model. The logical model revolves around the needs of the business, not the database, although the
needs of the business are used to establish the needs of the database. Logical modeling involves
gathering information about business processes, business entities (categories of data), and organizational
units. After this information is gathered, diagrams and reports are produced including entity relationship
diagrams, business process diagrams, and eventually process flow diagrams. The diagrams produced
should show the processes and data that exists, as well as the relationships between business processes
and data. Logical modeling should accurately render a visual representation of the activities and data
relevant to a particular business.
The diagrams and documentation generated during logical modeling is used to determine whether the
requirements of the business have been completely gathered. Management, developers, and end users
alike review these diagrams and documentation to determine if more work is required before physical
modeling commences.
Logical modeling affects not only the direction of database design, but also indirectly affects the
performance and administration of an implemented database. When time is invested performing logical
modeling, more options become available for planning the design of the physical database.
Typical deliverables of logical modeling include
Physical Modeling
Physical modeling involves the actual design of a database according to the requirements that were
established during logical modeling. Logical modeling mainly involves gathering the requirements of the
business, with the latter part of logical modeling directed toward the goals and requirements of the
database. Physical modeling deals with the conversion of the logical, or business model, into a relational
database model. When physical modeling occurs, objects are being defined at the schema level. A
schema is a group of related objects in a database. A database design effort is normally associated with
one schema.
During physical modeling, objects such as tables and columns are created based on entities and
attributes that were defined during logical modeling. Constraints are also defined, including primary keys,
foreign keys, other unique keys, and check constraints. Views can be created from database tables to
summarize data or to simply provide the user with another perspective of certain data. Other objects such
as indexes and snapshots can also be defined during physical modeling. Physical modeling is when all
the pieces come together to complete the process of defining a database for a business.
Physical modeling is database software specific, meaning that the objects defined during physical
modeling can vary depending on the relational database software being used. For example, most
relational database systems have variations with the way data types are represented and the way data is
stored, although basic data types are conceptually the same among different implementations.
Additionally, some database systems have objects that are not available in other database systems.
e software might only be available for Windows NT systems, whereas other software products such as Oracle are available on a wider rang
Conclusion
Understanding the difference between logical and physical modeling will help you build better organized
and more effective database systems. This article described both of these models.
There are various software development approaches defined and designed which are
used/employed during development process of software, these approaches are also
referred as Software Development Process Models (e.g. Waterfall model, incremental
model, V-model, iterative model, etc.). Each process model follows a particular life cycle in
order to ensure success in process of software development.
Software life cycle models describe phases of the software cycle and the order in which
those phases are executed. Each phase produces deliverables required by the next phase
in the life cycle. Requirements are translated into design. Code is produced according to the
design which is called development phase. After coding and development the testing
verifies the deliverable of the implementation phase against requirements.
There are following six phases in every Software development life cycle model:
1.
2.
Design
3.
Implementation or coding
4.
Testing
5.
Deployment
6.
Maintenance
6) Maintenance: Once when the customers starts using the developed system then the
actual problems comes up and needs to be solved from time to time. This process where
the care is taken for the developed product is known as maintenance.
The Waterfall Model was first Process Model to be introduced. It is also referred to as
alinear-sequential life cycle model. It is very simple to understand and use. In a waterfall
model, each phase must be completed fully before the next phase can begin. This type of
model is basically used for the for the project which is small and there are no uncertain
requirements. At the end of each phase, a review takes place to determine if the project is
on the right path and whether or not to continue or discard the project. In this model the
testing starts only after the development is complete. In waterfall model phases do not
overlap.
This model is used only when the requirements are very well known, clear and fixed.
Technology is understood.
Very less customer enter action is involved during the development of the product. Once the
product is ready then only it can be demoed to the end users. Once the product is
developed and if any failure occurs then the cost of fixing such issues are very high,
because we need to update everywhere from document till the logic.
V- model means Verification and Validation model. Just like the waterfall model, the VShaped life cycle is a sequential path of execution of processes. Each phase must be
completed before the next phase begins. Testing of the product is planned in parallel with a
corresponding phase of development.
Diagram of V-model:
The implementation phase is, again, where all coding takes place. Once coding is
complete, the path of execution continues up the right side of the V where the test plans
developed earlier are now put to use.
Coding: This is at the bottom of the V-Shape model. Module design is converted into code
by developers.
Advantages of V-model:
Testing activities like planning, test designing happens well before coding. This
saves a lot of time. Hence higher chance of success over the waterfall model.
Proactive defect tracking that is defects are found at early stage.
Works well for small projects where requirements are easily understood.
Disadvantages of V-model:
The V-shaped model should be used for small to medium sized projects where
High confidence of customer is required for choosing the V-Shaped model approach. Since,
no prototypes are produced, there is a very high risk involved in meeting customer
expectations.