assignment for kt

It is important for an organization to spend a substantial amount of time during the planning stage before starting to develop desired application to meet the few identified needs. A good plan will increase the chances of the final product to meet all the organization requirements and safe time in development because all the needs have been keenly analyzed. Planning will also save wastage of organization resources on doing the wrong thing and later realizing they needed a different application.

The architecture of a database management system alludes to the configuration of the real segments of the framework and how they are identified with one another. The commonest database architecture is the three-level architecture, regularly called the ANSI-SPARC model. The three principle parts of the three-level design portray three levels of abstraction inside of the database framework (Humphries et al., 1999). These are, first level is external, second is conceptual and the third one is internal. The reason for these deliberation levels is to give data autonomy. That is, every level is isolated from the level above it and the level underneath it.

The three levels inside of the database architecture speak to various perspectives of data. The data is not held in three unique areas; it is held in only one place, that is, the database. The three levels (external, conceptual and internal) are just portrayals of information. At the point when a client demands information by composing a database query, they utilize the structures contained in their perspective of the database (their external schema). The client's solicitation must be changed over from one of the external perspectives to the conceptual perspective of the database and afterward to the internal perspective of the database (Inmon et al., 2008). In this manner, it must be conceivable to change over between the distinctive levels in the design. The procedure of communicating one level in terms of another is known as a mapping. Mapping changes over the substance of one level into another. For instance, when the client demands information from the database utilizing an external schema it is mapped to the conceptual schema and after that to the internal schema.

The principle motivation behind the three pattern design is to separate every user's perspective of the database from different users. With respect to Inmon et al (2008), this separation is important because:

· Users ought to have the capacity to see the information in the structure that best suits their necessities. The same data might be seen in more than one way.

· Users are not worried with how the database has been physically executed, rather are intrigued just in the substance of the database.

· The physical usage of the database can be changed by the database administrator without influencing how the clients see the information.

· Changing the physical structures used to execute the database ought not to influence the intelligent structures in the database, for instance, the tables or relations.

· The global perspective of the database can be changed without influencing the clients. Thus, new information might be added to the database without influencing existing clients.

Describe Data Independence

The three-level architecture gives data independence. According to Humphries et al (1999) data independence is the ability to change the composition at one level of a database framework without changing the schema at the following higher level. There are two sorts of data autonomy given by the three-level architecture:

Logical independence – as per Inmon et al (2008), sensible information autonomy is the invulnerability of the external schema to changes in the conceptual level. At the point when new data entity is added to the conceptual level it is not important to change the external level or application programs in light of the fact that the information they utilize is unaffected by the new information.

Physical independence – this is the ability to change the internal outline without changing the conceptual schema or external pattern (Inmon et al., 2008). Changes in the internal level, does not require change to the conceptual level.

The Differences between a DA and a DBA

A few associations define separate parts for the business angles and the specialized parts of data. The business parts of data are adjusted to data administrator, though the more technical parts are taken care of by database administrator. The essential part of a Database Administrator is to store and deal with the data in the database. They are in charge of investigating the substance in the database (Mullins, 2002). They perform each of the exercises identified with keeping up the database and in charge of designing, and implementing the database. Additionally they are responsible to move down information frequently and keep it from unapproved access. In the other hand, Data Administrator is in charge of characterizing data components, data names and their association with the database analyst. The main responsibility is to the manner by which to install and design the RDBMS applications furthermore they need to know the prerequisites of the product application as far as functions and guarantee the data integrity is maintained. Moreover, the DA manages metadata, instead of the DBA, who manages data. Metadata is frequently portrayed as data about data; all more precisely, metadata is the depiction of the data and data interfaces required by the business (Mullins, 2002).

Pros and Cons of having a separate DA and DBA or the need for 1 person doing it all

In essence, not each organization has data administration capacity. Without doubt, numerous associations join data administration into the database administration role. This enables the organization to safe the extra cost involved with hiring the services of the data administrator. In the contrary, the organization may suffer from mixing the roles of both the DBA and the DA which might lead to little benefits from the database system. When an organization separates the business aspects and the technical aspects of data by hiring both the DBA and the DA, they stand to reap maximum benefits from the database system which will highly contribute to the organization growth and better services to its customers. In the other hand, the cost of running the organization will increase but in the long run there will be a positive impact to the organization. I will take this opportunity to advice my organization to consider having the DBA and DA roles separated so as to realize the full benefits of a database application system.

Databases have become more and more indispensable in our daily lives. They are now everywhere and it is hard to imagine the world without databases. An Entity Relationship Diagram (ERD) is a graphical representation of an information system that shows the relationship between people, objects, concepts, or events within a system. An ERD is the foundation of a relational database. An ERD is a model of an organizational database requirements within three main components which are namely entities, attributes, and relationships. Entities, attributes, and relationships can be represented in three ways; with a conceptual model, a logical model, or a physical model. An ERD is an example of a physical model.

An Entity Relationship Diagram (ERD) is basically a snapshot or a summary of various data structures which are designed to show the entities that are present in a database as well as the relationship between the tables of a that particular database. ERDs assist in database design, implementation, as well as documentation in the following ways:

Visual Representation- ERDs provide visual representation of the design of a database, the visual representation allows the database designer to focus on the way the database will primarily work with all the interactions and the data flows.

Effective Communication- A ERD clearly communicates the key entities in a particular database and their relationship with each other.

Simple to understand- ERDs are simple to understand and easy to understand to even those without the knowledge of database design

High Flexibility- ERD models are quite flexible to use as other relationships can be easily derived from the existing relationships.

Multiplicity in entity relationships allows the database designer to understand the relationship between the different entities of the database or information system being developed. There are four types of multiplicities which include one-to-one, one-to-many, many-to-one, and many-to-many.

After thorough analysis of the current Access database system utilized by the company and the additional requirements that the database system does not meet, I have created an enhanced ERD to meet all the necessary requirements. The ERD is shown in the diagram below:

Enhanced Entity Relationship Diagram

Customer