Rich pictures

Purpose

Rich pictures were particularly developed as part of Peter  Checkland’s Soft Systems Methodology for gathering information about a complex situation (Checkland, 1981; Checkland and Scholes, 1990). The idea of using drawings or pictures to think about issues is common to several problem solving or creative thinking methods (including therapy) because our intuitive consciousness communicates more easily in impressions and symbols than in words. Drawings can both evoke and record insight into a situation, and different visualization techniques such as visual brainstorming, imagery manipulation and creative dreaming have been developed emphasizing one of these two purposes over the other (Garfield, 1976; McKim, 1980; Shone, 1984; Parker, 1990).

Rich pictures are drawn at the pre-analysis stage, before you know clearly which parts of the situation should best be regarded as process and which as structure.

Part of a rich picture of a telephone helpline situation

Rich pictures (situation summaries) are used to depict complicated situations. They are an attempt to encapsulate the real situation through a no- holds-barred, cartoon representation of all the ideas covered already layout, connections, relationships, influences, cause-and-effect, and so on. As well as these objective notions, rich pictures should depict subjective elements such as character and characteristics, points of view and prejudices, spirit and human nature. If you are working with a client you should try to draw these from the actors themselves, at least initially, rather than focusing on your own interpretation of the situation.

Elements:

• pictorial symbols;
• keywords;
• cartoons;
• sketches;
• symbols;
• title.

Conventions

1. To help interpret a situation, choose symbols, scenes or images that represent the situation. Use as many colours as necessary and draw the symbols on a large piece of paper. Try not to get too carried away with the fun and challenge to your ingenuity in finding pictorial symbols.
2. Put in whatever connections you see between your pictorial symbols: avoid producing merely an unconnected set. Places where connections are lacking may later prove significant.
3. Avoid too much writing, either as commentary or as ‘word bubbles’ coming from people’s mouths (but a brief summary can help explain the diagram to other people).
4. Don’t include systems boundaries or specific references to systems in any way (see below).

Guidelines

1. A rich picture is an attempt to assemble everything that might be relevant to a complex situation. You should somehow represent every observation that occurs to you or that you gleaned from your initial survey.
2. Fall back on words only where ideas fail you for a sketch that encapsulates your meaning.
3. You should not seek to impose any style or structure on your picture. Place the elements on your sheet wherever your instinct prompts. At a later stage you may find that the placement itself has a message for you.
4. If you ‘don’t know where to begin’, then the following sequence may help to get you started:
   
   
   1. first look for the elements of structure in the situation (these are the parts of the situation that change relatively slowly over time and are relatively stable, the people, the set-ups, the command hierarchy, perhaps);
   2. next look for elements of process within the situation (these are the things that are in a state of change: the activities that are going on);
   3. then look for the ways in which the structure and the processes interact. Doing this will give you an idea of the climate of the situation. That is, the ways in which the structure and the processes relate to each other.
5. Avoid thinking in systems terms. That is, using ideas like: ‘Well, the situation is made up of a marketing system and a production system and a quality control system’. There are two reasons for this. The first is that the word ‘system’ implies organized interconnections and it may be precisely the absence of such organized interconnectedness that lies at the heart of the matter: therefore, by assuming its existence (by the use of the word system) you may be missing the point. Note, however, that this does not mean that there won’t be some sort of link or connection between your graphics, as mentioned above. The second reason is that doing so will channel you down a particular line of thought, namely the search for ways of making these systems more efficient.
6. Make sure that your picture includes not only the factual data about the situation, but also the subjective information.
7. Look at the social roles that are regarded within the situation as meaningful by those involved, and look at the kinds of behaviour expected from people in those roles. If you see any conflicts, indicate them.
8. Finally, include yourself in the picture. Make sure that your roles and relationships in the situation are clear. Remember that you are not an objective observer, but someone with a set of values, beliefs and norms that colour your perceptions.

The main principle of a rich picture is to assist us the analyst to gain an admiration of the problem situation. As it is understood in Soft Systems Methodology (SSM), rich pictures are used as a means to signify the situation of anxiety and include elements which influence the problem for organisation, but which would not perhaps be picked up using more formal methods.

Soft systems methodology emphasizes the value of rich pictures. Rich Pictures is an innovative way of turning complex systems, thoughts and everyday business issues into a neat format that everyone can understand easily. These seek to explore and summarise issues much more pictorially and graphically than the methods like documenting, reporting. They can be extremely intuitive and can also compress a lot of information into a single picture.

Rich pictures can be very useful in forming a backdrop to subsequent analysis, acting as an aide memoire to allow the group continually to refer back and check they are addressing all the relevant issues. The rich picture of our Problem Scenario shows the many interacting systems and issues that relate to the organisation which has developed over particular location. Within a solitary image all the mean points and concerns have been detained and may be corresponded to those apprehensive in choosing what action to take.

The above rich picture includes the struc­ture of  Environment. This Struc­ture refers to those parts of the sit­u­a­tion which are slow to change and rel­a­tively sta­ble. They may include things like organ­i­sa­tional struc­ture, phys­i­cal lay­out and all the peo­ple who are affected by the sit­u­a­tion. And also it includes only enough struc­ture to allow you to record the process and concerns. At the same time it embraces the concerns or issues which capture a particular actor’s motivations for participating in the situation. The different motivations give rise to the various perspectives each actor has.

It also includes the process of Organisation which refers to the transformation that go on within the structure. These transformations might be part of a flow of goods which are being utilised in that firm, existing documents which are already there in that problem organisation or data of that particular organisation. But the rich picture will not capture all aspects of process. The above Rich picture represents structure, processes and issues of the environment, which could be relevant to the problem definition, and try giving an impression of the charity organisational climate. Although they can often contain imprecise or confusing illustration between their processes and correspond the problem situation clearly or not very clearly.

Many analysts are scared of using rich pictures, because they feel their artistic skills are not adequate. However, with modern drawing tools in Office tools and inventive use of clip art, this is now much less of a problem. The act of drawing a rich picture is functional in itself because:  lack of space on the paper forces decisions on what is really important (and what are side issues or points of detail for further layers of rich pictures); It helps people to visualize and discuss their own role in the organisation; It can be used to define the aspects of the organisation which are intended to be covered, by the information system; It can be used to show up the worries of individuals, potential conflicts, and political issues.

Once the rich picture has been drawn, it is useful in identifying two main aspects of the human activity system. The first is to identify the primary tasks. Searching for primary tasks is a way of posing and answering the question: 'What is really central to the problem situation?' For example, it could be argued that the organisation aims to give an excellent service to its customers (the public) (which might be implied by the diagram) or increase standards in its profession (which is not implied by the diagram). Everything else is carried out to achieve that end. Primary tasks are central to the creation of this information system, because the information system is normally set up to achieve or support that primary task of the organisation environment. 

The second way that the rich picture is of particular value is in identifying issues of that problem area. These are topics or matters which are of concern. They may be the subject of dispute. They represent the (often unstated) question marks hanging over the 4/5 situation. This process of identifying the issues will lead to some debate on potential changes. It might be possible for these issues to be resolved at this stage, but it is essential that they are understood. Issues are important features, as the behaviour resulting from them could cause the formal information system to fail. Unless at least some of them have been resolved, the information system will have little chance of success. In some situations, the issues can be more important than the tasks.

The rich picture can help the owners of the problem sort out the fundamentals of situation, both to clarify their own thinking and decision making and also to explain these fundamentals to all the concerned parties. The rich picture becomes an abstract of all that significant in the circumstance. An analysis of the rich picture will help in the process of from 'thinking about the problem situation' to 'thinking about what can be done about"' problem situation'.

The above description of Richpicture is taken from my own Assignment task on my Bsc Final Year ISE Coursework.

12 CODD RULES

Rules for satisfying to become a RDBMS

Rule 0: The system must qualify as relational, as a database, and as a management system.

For a system to qualify as a relational database management system (RDBMS), that system must use its relational facilities (exclusively) to manage the database.

Rule 1: The information rule:                                                                      

All information in the database is to be represented in one and only one way, namely by values in column positions within rows of tables.

Rule 2: The guaranteed access rule:

All data must be accessible. This rule is essentially a restatement of the fundamental requirement for primary keys. It says that every individual scalar value in the database must be logically addressable by specifying the name of the containing table, the name of the containing column and the primary key value of the containing row.

Rule 3: Systematic treatment of null values:

The DBMS must allow each field to remain null (or empty). Specifically, it must support a representation of "missing information and inapplicable information" that is systematic, distinct from all regular values (for example, "distinct from zero or any other number", in the case of numeric values), and independent of data type. It is also implied that such representations must be manipulated by the DBMS in a systematic way.

Rule 4: Active online catalog based on the relational model:

The system must support an online, inline, relational catalog that is accessible to authorized users by means of their regular query language. That is, users must be able to access the database's structure (catalog) using the same query language that they use to access the database's data.

Rule 5: The comprehensive data sublanguage rule:

The system must support at least one relational language that

1.     Has a linear syntax

2.     Can be used both interactively and within application programs,

3.     Supports data definition operations (including view definitions), data manipulation operations (update as well as retrieval), security and integrity constraints, and transaction management operations (begin, commit, and rollback).

Rule 6: The view updating rule:

All views that are theoretically updatable must be updatable by the system.

Rule 7: High-level insert, update, and delete:

The system must support set-at-a-time insert, update, and delete operators. This means that data can be retrieved from a relational database in sets constructed of data from multiple rows and/or multiple tables. This rule states that insert, update, and delete operations should be supported for any retrievable set rather than just for a single row in a single table.

Rule 8: Physical data independence:

Changes to the physical level (how the data is stored, whether in arrays or linked lists etc.) must not require a change to an application based on the structure.

Rule 9: Logical data independence:

Changes to the logical level (tables, columns, rows, and so on) must not require a change to an application based on the structure. Logical data independence is more difficult to achieve than physical data independence.

Rule 10: Integrity independence:

Integrity constraints must be specified separately from application programs and stored in the catalog. It must be possible to change such constraints as and when appropriate without unnecessarily affecting existing applications.

Rule 11: Distribution independence:

The distribution of portions of the database to various locations should be invisible to users of the database. Existing applications should continue to operate successfully:

1.     when a distributed version of the DBMS is first introduced; and

2.     when existing distributed data are redistributed around the system.

Rule 12: The nonsubversion rule:

If the system provides a low-level (record-at-a-time) interface, then that interface cannot be used to subvert the system, for example, bypassing a relational security or integrity constraint.

Many Lankan Do not know about this...

ICTA

Information and Communications Technology (ICT) is an increasingly powerful tool for participating in global markets, promoting political accountability, improving the delivery of basic services and enhancing local development opportunities. However, without an innovative ICT strategy many people will be left behind. The Information and Communication Technology Agency (ICTA) of Sri Lanka is the single apex body involved in ICT policy and direction for the nation. Wholly owned by the Government of Sri Lanka, ICTA is the implementing organization of the e-Sri Lanka Initiative. Major donors including the World Bank will be funding a number of the Agency’s initiatives.

Our Vision

"To harness ICT as a lever for economic and social advancement
by taking the dividends of ICT to every village, to every citizen, to
every business & to re-engineer the way government
thinks & works"

Thanks to : ICTA 

Are you Looking for a TOP up in Computing.. Here we go

BSc (Hons) Computing Courses UK university qualifications by distance learning Choose when, how and where you learn Lower fees than traditional university study A choice of UK University courses to suit your career and aspirations Flexible payment packages to suit your budget Tailored and individual tutor support and advice Free membership of RDI's International Management Academy

DBMS

What is a Database Management System?

A database management system (or DBMS) is essentially nothing more than a computerized data- keeping system. Users of the system are given facilities to perform several kinds of operations on such a system for either manipulation of the data in the database or the management of the database structure itself. Database Management Systems (DBMSs) are categorized according to their data structures or types.

There are several types of databases that can be used on a mainframe to exploit z/OS: inverted list, hierarchic, network, or relational.
Mainframe sites tend to use a hierarchical model when the data structure (not data values) of the data needed for an application is relatively static. For example, a Bill of Material (BOM) database structure always has a high level assembly part number, and several levels of components with subcomponents. The structure usually has a component forecast, cost, and pricing data, and so on. The structure of the data for a BOM application rarely changes, and new data elements (not values) are rarely identified. An application normally starts at the top with the assembly part number, and goes down to the detail components.

Role of a Database Management System.

A Database management system provides the technology for achieving more effective and efficient integrated information systems. The database technology is a step beyond the file-access techniques available earlier. Usually, database management systems are developed at the top of the file-access software. As shown in the picture 1, the application programs that use the database management systems are at the top most level of the hierarchy.

The major objective of designing any database management package is to provide its users an appreciably higher level framework (as compared to the file-access facilities being availed through COBOL, BASIC, FORTAN and other programming languages) such that the relevant interrelated data can be collected and stored together, to serve multiple applications.

Basic Components of a Database Management System

A Database Management System creates and maintains a database, loads and manipulates data within a database. It consists of following components:

V A data description language (DDL) to translate the schema, thereby creating a logical and physical layout for the database.

V Procedures for adding new data into the database and modifying and retrieving data there form.

V A query language translator to translate queries written in a source language to a sequence of procedure calls for retrieving data from the database.

V System software modules for file and buffer management, report generation, controlling concurrency, recovery from failure and to enforce security.

More on the DBMS….

A DBMS is a complex set of software programs that controls the organization, storage, management, and retrieval of data in a database. DBMS are categorized according to their data structures or types, some time DBMS is also known as Data base Manager. It is a set of prewritten programs that are used to store, update and retrieve a Database. A DBMS includes:

1. A modeling language to define the schema of each database hosted in the DBMS, according to the DBMS data model.
• The four most common types of organizations are the hierarchical, network, relational and object models. Inverted lists and other methods are also used. A given database management system may provide one or more of the four models. The optimal structure depends on the natural organization of the application's data, and on the application's requirements (which include transaction rate (speed), reliability, maintainability, scalability, and cost).
• The dominant model in use today is the ad hoc one embedded in SQL, despite the objections of purists who believe this model is a corruption of the relational model, since it violates several of its fundamental principles for the sake of practicality and performance. Many DBMSs also support the Open Database Connectivity API that supports a standard way for programmers to access the DBMS.
2. Data structures (fields, records, files and objects) optimized to deal with very large amounts of data stored on a permanent data storage device (which implies relatively slow access compared to volatile main memory).
3. A database query language and report writer to allow users to interactively interrogate the database, analyze its data and update it according to the users privileges on data.
• It also controls the security of the database.
• Data security prevents unauthorized users from viewing or updating the database. Using passwords, users are allowed access to the entire database or subsets of it called subschemas. For example, an employee database can contain all the data about an individual employee, but one group of users may be authorized to view only payroll data, while others are allowed access to only work history and medical data.
• If the DBMS provides a way to interactively enter and update the database, as well as interrogate it, this capability allows for managing personal databases. However, it may not leave an audit trail of actions or provide the kinds of controls necessary in a multi-user organization. These controls are only available when a set of application programs are customized for each data entry and updating function.
4. A transaction mechanism, that ideally would guarantee the ACID properties, in order to ensure data integrity, despite concurrent user accesses (concurrency control), and faults (fault tolerance).
• It also maintains the integrity of the data in the database.
• The DBMS can maintain the integrity of the database by not allowing more than one user to update the same record at the same time. The DBMS can help prevent duplicate records via unique index constraints; for example, no two customers with the same customer numbers (key fields) can be entered into the database. See ACID properties for more information (Redundancy avoidance).

The DBMS accepts requests for data from the application program and instructs the operating system to transfer the appropriate data.
When a DBMS is used, information systems can be changed much more easily as the organization's information requirements change. New categories of data can be added to the database without disruption to the existing system.
Organizations may use one kind of DBMS for daily transaction processing and then move the detail onto another computer that uses another DBMS better suited for random inquiries and analysis. Overall systems design decisions are performed by data administrators and systems analysts. Detailed database design is performed by database administrators.
Database servers are specially designed computers that hold the actual databases and run only the DBMS and related software. Database servers are usually multiprocessor computers, with RAID disk arrays used for stable storage. Connected to one or more servers via a high-speed channel, hardware database accelerators are also used in large volume transaction processing environments.
DBMSs are found at the heart of most database applications. Sometimes DBMSs are built around a private multitasking kernel with built-in networking support although nowadays these functions are left to the operating system.

Logical view and physical view

A database management system provides the ability for many different users to share data and process resources. But as there can be many different users, there are many different database needs. The question now is: How can a single, unified database meet the differing requirement of so many users?
A DBMS minimizes these problems by providing two views of the database data: a physical view and a logical view. The physical view deals with the actual, physical arrangement and location of data in the direct access storage devices (DASDs). Database specialists use the physical view to make efficient use of storage and processing resources. Users, however, may wish to see data differently from how they are stored, and they do not want to know all the technical details of physical storage. After all, a business user is primarily interested in using the information, not in how it is stored. The logical view/user’s view, of a database program represents data in a format that is meaningful to a user and to the software programs that process those data. That is, the logical view tells the user, in user terms, what is in the database. One strength of a DBMS is that while there is only one physical view of the data, there can be an endless number of different logical views. This feature allows users to see database information in a more business-related way rather than from a technical, processing viewpoint. Thus the logical view refers to the way user views data, and the physical view to the way the data are physically stored and processed.

Features and capabilities of DBMS

A DBMS can be characterized as an "attribute management system" where attributes are small chunks of information that describe something. For example, "colour" is an attribute of a car. The value of the attribute may be a color such as "red", "blue" or "silver".
Alternatively, and especially in connection with the relational model of database management, the relation between attributes drawn from a specified set of domains can be seen as being primary. For instance, the database might indicate that a car that was originally "red" might fade to "pink" in time, provided it was of some particular "make" with an inferior paint job. Such higher arity relationships provide information on all of the underlying domains at the same time, with none of them being privileged above the others.
Throughout recent history specialized databases have existed for scientific, geospatial, imaging, and document storage and like uses. Functionality drawn from such applications has lately begun appearing in mainstream DBMSs as well. However, the main focus there, at least when aimed at the commercial data processing market, is still on descriptive attributes on repetitive record structures.
Thus, the DBMSs of today roll together frequently-needed services or features of attribute management. By externalizing such functionality to the DBMS, applications effectively share code with each other and are relieved of much internal complexity. Features commonly offered by database management systems include:

Query ability
Querying is the process of requesting attribute information from various perspectives and combinations of factors. Example: "How many 2-door cars in Texas are green?"
A database query language and report writer allow users to interactively interrogate the database, analyze its data and update it according to the users privileges on data. It also controls the security of the database.
Data security prevents unauthorized users from viewing or updating the database. Using passwords, users are allowed access to the entire database or subsets of it called subschema. For example, an employee database can contain all the data about an individual employee, but one group of users may be authorized to view only payroll data, while others are allowed access to only work history and medical data. If the DBMS provides a way to interactively enter and update the database, as well as interrogate it, this capability allows for managing personal databases. However it may not leave an audit trail of actions or provide the kinds of controls necessary in a multi-user organization. These controls are only available when a set of application programs are customized for each data entry and updating function.

Backup and replication
Copies of attributes need to be made regularly in case primary disks or other equipment fails. A periodic copy of attributes may also be created for a distant organization that cannot readily access the original. DBMS usually provide utilities to facilitate the process of extracting and disseminating attribute sets. When data is replicated between database servers, so that the information remains consistent throughout the database system and users cannot tell or even know which server in the DBMS they are using, the system is said to exhibit replication transparency.

Rule enforcement
Often one wants to apply rules to attributes so that the attributes are clean and reliable. For example, we may have a rule that says each car can have only one engine associated with it (identified by Engine Number). If somebody tries to associate a second engine with a given car, we want the DBMS to deny such a request and display an error message. However, with changes in the model specification such as, in this example, hybrid gas-electric cars, rules may need to change. Ideally such rules should be able to be added and removed as needed without significant data layout redesign.

Security
Often it is desirable to limit who can see or change which attributes or groups of attributes. This may be managed directly by individual, or by the assignment of individuals and privileges to groups, or (in the most elaborate models) through the assignment of individuals and groups to roles which are then granted entitlements.

Computation
There are common computations requested on attributes such as counting, summing, averaging, sorting, grouping, cross-referencing, etc. Rather than have each computer application implement these from scratch, they can rely on the DBMS to supply such calculations. All arithmetical work to perform by computer is called a computation.

Change and access logging
Often one wants to know who accessed what attributes, what was changed, and when it was changed. Logging services allow this by keeping a record of access occurrences and changes.

Automated optimization

If there are frequently occurring usage patterns or requests, some DBMS can adjust themselves to improve the speed of those interactions. In some cases the DBMS will merely provide tools to monitor performance, allowing a human expert to make the necessary adjustments after reviewing the statistics collected.

Meta-data repository

Metadata (also spelled meta-data) is data describing data. For example, a listing that describes what attributes are allowed to be in data sets is called "meta-information". The meta-data is also known as data about data.
Histories of DBMS Databases have been in use since the earliest days of electronic computing. Unlike modern systems which can be applied to widely different databases and needs, the vast majority of older systems were tightly linked to the custom databases in order to gain speed at the expense of flexibility. Originally DBMSs were found only in large organizations with the computer hardware needed to support large data sets.

Navigational DBMS

As computers grew in capability, this trade-off became increasingly unnecessary and a number of general-purpose database systems emerged; by the mid-1960s there were a number of such systems in commercial use. Interest in a standard began to grow, and Charles Bachman, author of one such product, IDS, founded the Database Task Group within CODASYL, the group responsible for the creation and standardization of COBOL. In 1971 they delivered their standard, which generally became known as the Codasyl approach, and soon there were a number of commercial products based on it available.
The Codasyl approach was based on the "manual" navigation of a linked data set which was formed into a large network. When the database was first opened, the program was handed back a link to the first record in the database, which also contained pointers to other pieces of data. To find any particular record the programmer had to step through these pointers one at a time until the required record was returned. Simple queries like "find all the people in Sweden" required the program to walk the entire data set and collect the matching results. There was, essentially, no concept of "find" or "search". This might sound like a serious limitation today, but in an era when the data was most often stored on magnetic tape such operations were too expensive to contemplate anyway.
IBM also had their own DBMS system in 1968, known as IMS. IMS was a development of software written for the Apollo program on the System/360. IMS was generally similar in concept to Codasyl, but used a strict hierarchy for its model of data navigation instead of Codasyl's network model.
Both concepts later became known as navigational databases due to the way data was accessed, and Bachman's 1973 Turing Award presentation was The Programmer as Navigator.
IMS is classified as a hierarchical database. IDS and IDMS (both CODASYL databases) as well as CINCOMs TOTAL database are classified as network databases.

Relational DBMS

Edgar Codd worked at IBM in San Jose, California, in one of their offshoot offices that was primarily involved in the development of hard disk systems. He was unhappy with the navigational model of the Codasyl approach, notably the lack of a "search" facility which was becoming increasingly useful. In 1970, he wrote a number of papers that outlined a new approach to database construction that eventually culminated in the groundbreaking A Relational Model of Data for Large Shared Data Banks.

In this paper, he described a new system for storing and working with large databases. Instead of records being stored in some sort of linked list of free-form records as in Codasyl, Codd's idea was to use a "table" of fixed-length records. A linked-list system would be very inefficient when storing "sparse" databases where some of the data for any one record could be left empty. The relational model solved this by splitting the data into a series of normalized tables, with optional elements being moved out of the main table to where they would take up room only if needed.

In the relational model, related records are linked together with a "key".

For instance, a common use of a database system is to track information about users, their name, login information, various addresses and phone numbers. In the navigational approach all of these data would be placed in a single record, and unused items would simply not be placed in the database. In the relational approach, the data would be normalized into a user table, an address table and a phone number table (for instance). Records would be created in these optional tables only if the address or phone numbers were actually provided.

Linking the information back together is the key to this system. In the relational model, some bit of information was used as a "key", uniquely defining a particular record. When information was being collected about a user, information stored in the optional (or related) tables would be found by searching for this key. For instance, if the login name of a user is unique, addresses and phone numbers for that user would be recorded with the login name as its key. This "re-linking" of related data back into a single collection is something that traditional computer languages are not designed for.

Just as the navigational approach would require programs to loop in order to collect records, the relational approach would require loops to collect information about any one record. Codd's solution to the necessary looping was a set-oriented language, a suggestion that would later spawn the ubiquitous SQL. Using a branch of mathematics known as tuple calculus, he demonstrated that such a system could support all the operations of normal databases (inserting, updating etc.) as well as providing a simple system for finding and returning sets of data in a single operation.

Codd's paper was picked up by two people at Berkeley, Eugene Wong and Michael Stonebreaker. They started a project known as INGRES using funding that had already been allocated for a geographical database project, using student programmers to produce code. Beginning in 1973, INGRES delivered its first test products which were generally ready for widespread use in 1979. During this time, a number of people had moved "through" the group — perhaps as many as 30 people worked on the project, about five at a time. INGRES was similar to System R in a number of ways, including the use of a "language" for data access, known as QUEL — QUEL was in fact relational, having been based on Codd's own Alpha language, but has since been corrupted to follow SQL, thus violating much the same concepts of the relational model as SQL itself.

IBM itself did only one test implementation of the relational model, PRTV, and a production one, Business System 12, both now discontinued. Honeywell did MRDS for Multics, and now there are two new implementations: Alphora Dataphor and Rel. All other DBMS implementations usually called relational are actually SQL DBMSs.
In 1968, the University of Michigan began development of the Micro DBMS relational database management system. It was used to manage very large data sets by the US Department of Labor, the Environmental Protection Agency and researchers from University of Alberta, the University of Michigan and Wayne State University. It ran on mainframe computers using Michigan Terminal System. The system remained in production until 1996.

SQL DBMS

IBM started working on a prototype system loosely based on Codd's concepts as System R in the early 1970s — unfortunately, System R was conceived as a way of proving Codd's ideas unimplementable, and thus the project was delivered to a group of programmers who were not under Codd's supervision, never understood his ideas fully and ended up violating several fundamentals of the relational model. The first "quickie" version was ready in 1974/5, and work then started on multi-table systems in which the data could be broken down so that all of the data for a record (much of which is often optional) did not have to be stored in a single large "chunk". Subsequent multi-user versions were tested by customers in 1978 and 1979, by which time a standardized query language, SQL, had been added. Codd's ideas were establishing themselves as both workable and superior to Codasyl, pushing IBM to develop a true production version of System R, known as SQL/DS, and, later, Database 2 (DB2).

Many of the people involved with INGRES became convinced of the future commercial success of such systems, and formed their own companies to commercialize the work but with an SQL interface. Sybase, Informix, Nonstop SQL and eventually Ingress itself were all being sold as offshoots to the original INGRES product in the 1980s. Even Microsoft SQL Server is actually a re-built version of Sybase, and thus, INGRES. Only Larry Ellison's Oracle started from a different chain, based on IBM's papers on System R, and beat IBM to market when the first version was released in 1978.

Stonebreaker went on to apply the lessons from INGRES to develop a new database, Postures, which is now known as Posture SQL. Posture SQL is primarily used for global mission critical applications (the .org and .info domain name registries use it as their primary data store, as do many large companies and financial institutions).
In Sweden, Codd's paper was also read and Mimer SQL was developed from the mid-70s at Uppsala University. In 1984, this project was consolidated into an independent enterprise. In the early 1980s, Mimer introduced transaction handling for high robustness in applications, an idea that was subsequently implemented on most other DBMS.

Advantages of Database Management System.

• Improved strategic use of corporate data
• Reduced complexity of the organization’s information systems environment
• Reduced data redundancy and inconsistency
• Enhanced data integrity
• Application-data independence
• Improved security
• Reduced application development and maintenance costs
• Improved flexibility of information systems
• Increased access and availability of data and information
• Logical & Physical data independence

Disadvantages of Database Management System.

• The start-up cost to the database management system is very high.
• It takes times to design a database because the database systems are difficult and complex.
• Converting a manual file-based system to the database it takes much cost and small organizations can’t bear it.
• And the employees must initially they have to trained it also form much cost.
• We have to take back-up every time because if there is a problem occurs the entire data will be lost. So we have to be aware of that.