Enterprise Database
Enterprise database structures
All database, whether shared or not, must be defined. Definition starts with creation of a graphical enterprise data model, which in turn serves as a foundation for describing the schema, the formal definition of a database ‘s structure.
Enterprise Data Model
An enterprise data model is a graphical representation of the items (the entities) of interest about. Which data is captured and stored in the database. Enterprise databases typically store data about multiple entities, so the data model is sometimes termed an entity relationship data model.
Large database may store data about a large number of entities. However, the principle of data modeling is the same regardless of the number of entities and whether the database contains scientific, medical, engineering, financial or business data
Among the most common activities of business is the acceptance and processing of orders submitted by customers. Each order specific one or more items the customer seeks to purchase. At any point in time, a customer may have several orders at a company.
The entities in this database are customers, orders, and items (foods or products) ordered.
1. Each customer places one or more uniquely identified orders. Similarly, each order is associated with one specific customer (that is, two different customers cannot submit the uniquely identified order)
2. Each order contains one or more items.
Since a complex database may include data on many different entities, with many associations between them, the graphical representation of the enterprise data model can itself become quite complex. Database designers may spend hours developing the right data model before they begin actually creating the database.
Keep in mind that the enterprise data model is only a graphical representation and it is used as an aid to understanding the associations that the database must support.
Science relational databases are the most widespread type of database in use. the enterprise data model is usually a guide to understanding what relations must be created. The schema describes the resulting structure.
Schema
The formal name for the definition of a data base structure is its schema. The schema describes the names and attributes of each entity about which data are collected and stored. It provides a structure only; it does not include data items (the customer’s name or address, for example). You might think of the schema as the framework that outlines the structure of the database, with the database’s entities and the relations between them fitting within that framework. Figure 7.2 shows the schema’s relationship to other items in computer memory.
Each database has only one schema. Different databases use different schemas. Schema for relational databases recall form chapter 6 that relational databases are made up of data structured in a table format (a relation) consisting of rows and columns. The vertical columns, the horizontal rows of the relation are called records or topless. The vertical columns are the attributes, or field, and contain data items of a record. The item record can also refer to a grouping of data items that describes one specific occurrence of an entity. For example, a customer database includes records of all relevant data for each customer. Throughout this chapter, we will use this second definition of record.
The schema for a relational database identifies the database by a unique name and describes the relations contained within the database. A relation, in turn, is defined by its data items each of which is identified by a name, type (such as numeric or text) and length specification. In this manner, the schema gives a distinct structure to the relational database. The schema in figure 7.4 show customers, orders and item relations
Schema for object-oriented Databases
A newer type of database that is emerging alongside relational databases is the object-oriented database. An object is a focal point about which data and information are collected. Hence, the customers and orders in a data model-items. We called entities when discussing relational databases-are treated as object classes is an object-oriented database (figure7.5) object-oriented database systems store descriptive data and information about each object in an object in an object class (object refers to an individual instance in a class).
Data and information can be stored about both entities and objects. However, unlike relational databases, object-oriental databases also store actions (also called methods), instructions, or short programs telling the database how to process the object to produce specific information. For instance, a customer object could store the method for determining a customer’s credit-worthiness.
In a student database, the student object might include the method for determining the student’s grade point average.
The U.S. brokerage and investment from shearson Lehman brothers has created an object-oriented databases as the basis for many of its business activities. In this database are account objects (customers), contract objects (management agreement between shearson.lehman and firms that have signed investment (or tracts), and security objects (the descriptive detail of stocks, bonds, and stock options). Each object contains the descriptive data you would expect (names, address, prices, etc). Each also contains individual account (the object) can buy a security, just as if a broker were initiating the action, but without human intervention.
Object-oriented databases offer the capability to store more sophisticated type of data and information that relational database do for example, such complex information as three dimensional diagrams, animated ride clips, and photographs do not fit easily within the row-and-column, structure of relational database. However, because both data and processing instructions are part of object ascriptions, such information can be handled in an object-oriented database.
Both us-based Boeing Aircraft Company and England’s British Aerospace Ltd use object-oriented databases to maintain data about design, components, and maintenance of their multi million-dollar aircraft. These object database store detailed schematic drawings of the plane’s interiors, exteriors, and electronic components, including their extensive cable and writing systems. Manufacturing and cost information is also included in the database.
Before moving to object- oriented databases, both companies maintained their data on groups of separate databases. This system was costly and inefficient because it made it difficult for designer and engineers to get a complete picture of the repercussions of a particular action. For example, if the cost of a component changed, a project engineer would first have to search the component database to see where and in what quantity that component was being used. Then the engineer would have to search the order database to use to see if the component was being used in a specific aircraft configuration. Finally the engineer would have to go to the manufacturing database retrieve construction and assembly details related to the component. The process was both time-consuming and error-prone. Today, drawing, cost, manufacturing, and assembly details regarding. Components are all combined in the object database. Data and information are available, much more quickly, and the cost of managing data and information is lower.
The Information Technology in practice feature“Chubb Insurance objects streamline preparation of cross-border quotes” describes how this leading insurance underwriter relies on an object-oriented database to prepare quotations for complex insurance policies for everything from precious jewelry and art to international cargo shipments.
Other database schemas
Two other types of database schemas are worthy of mention here. Hierarchical databases store data in the form of a tree, where the relationship among data item is one-to-many (that is, one data item is linked to several other data items). In network databases, the relationship among the data item can be either one-to-many or many-to-many (that is, several data items are linked to several other data items). Detailed explanations of these types of database are beyond the scope of this discussion. It is enough to say here that hierarchical and network databases store data in a way that makes access to them faster for certain types of queries and slower for others.
Views
When a database is created, it is designed and stored according to a designer-determined. Structure of relations
As noted earlier in this chapter, however, users of shared databases often want to organize the data differently form the way in which they are stored. Database management systems address this need.
Users who want to organize data and information differently from the way in which they are stored in the database can use views to do so. A view is a subset of one or more databases, created either by extracting copies of records form a database or by merging copies of records from multiple databases. Like databases themselves, views have names and records composed of data items. As figure 7.6 shows, multiple views of data can be extracted from the database and used in any application, including calculation, sorting and generation of reports and other output.
In one sense, a view is simply a logical grouping of data. It gives the appearance that data have been moved of combined to meet processing requirement, although the database’s physical structure (schema) has not been altered. Savvy marketers purchase large databases and crate views to help them target advertising campaigns, as the Information Technology in practice feature “Database Marketing: The personal Art of persuasion”, explores in detail.
Viewing capabilities provide many benefits to business users.
Views allow users to examine data in different ways without changing the physical structure of the database.
Users can make changes in the data in a view while leaving the data in the database in its original from
Database security is maintained because individuals and applications can be kept away from sensitive data since they will process from the views rather than from the database itself sensitive or protected data are not included in a view.
Views shield user from changes in the physical database (for example, the structure of records so that they reside in a different location of a different sequence).
Views from multiple databases can be. Combined to meet business requirement.
Index
An important advantage offered by database and a DBMS is flexibility of retrieval views provide user with a way to assemble data form different data items.
An index is a data file that contains identifying information about each record (the record key) and its location in storage. The record key is a designated field used to distinguish one record from another. For example, the record key by which university students are typically identified is a unique student ID number. Each number is unique in that it is assigned to only one student.
A DBMS is able to automatically build and us index according to specifications prepared by the database administrator whose role is discussed later in this chapter. When an application, by the providing the record key request the DBMS to retrieve a record, the DBMS quickly searches the index to find the right record key. It then accesses the database to locate and retrieve the record so that it can be processed by the application.
As figure 7.8 shows, the index and search process takes place behind the scenes as part of processing therefore neither the index nor the search is visible to an individual user. Information about the student can be obtained by requesting, the database to locate and retrieve the record for the person with a specific ID number. To speed retrieval, the database system searches an index containing all student ID, and then retrieves date and information directly from the specified location. Indexes eliminate the need to search all records in a database to find the one need.
Database Administrator
The IT professional with the most extensive database management responsibilities is the database administrator is responsible for managing all activities and procedures related to an organization’s database. In some organizations, the database administrator is one person. In others, a team fulfills this function, with each team member responsible for some aspect of the data administration procedures.
Database Administration Procedures
Database administration means managing the database. This entailed doing what is necessary to develop and safeguard the database in the most beneficial way.
Procedures for data administration include sic areas of responsibility:
1. Database planning like any valuable resource, a database must be planned. Planning include being aware of and understanding business needs and user requirements, selecting the DBMS, developing standards for usage, and outlining security strategies.
2. Database Design
. To be as useful as possible, the database must be carefully designed. Designers define the records and objects including the schema, data names, and length specifications-that make up the database.
3. Database Creation
The database design is only a framework. The database becomes a reality when data are entered into the design and saved on a storage device.
4. Database Maintenance
As user’s needs and demands change, the database may need adjustment. New records or object may be added or changes may be made to the existing structures. Database maintenance pertains to the structure and organization of the database. Maintenance of the content of individual records (the data items) is the responsibility of those using the database, not the database administrator.
5. Analysis of Usage
Managing a database means monitoring how and when it is used. If data and information retrieval patterns change, the database administrator may decide that adjustments (maintenance) are needed to restructure the database to meet new user requests.
6. Creation and Monitoring of security procedures
The existence and integrity of the database must be safeguarded at all times. Developing, implementing, and monitoring security procedures are important parts of database administration.
Much of a database’s value comes from the procedures the database administrator uses to develop and maintain the database. These responsibilities are quite different from those of individual users or system programmers.
