PRACTICAL SUBMISSION FORM

The University of Sheffield CITY Liberal StudiesDepartment of Computer Science

MSc in Information Systems

PRACTICAL COVER SHEET

To be completed by the students (typewritten):Module Title

Organisation Theory & Information Systems

Semester & SessionFall 1998/1999

Instructors Name

Prof. Dr. E. Kehris

Practical Number1

Practical Title

Coursework Assignment - A Consultancy Report and Database Project Prototype for Bella Pigna Ltd.

Student Name

George Zagoridis

Videnovic Mikan

Submission Date Due07/04/2000

SignatureDeclaration:

All sentences or passages quoted in this practical from other people's work have been specifically acknowledged by clear cross referencing to author, work and page(s). I understand that failure to do this amounts to plagiarism and will be considered grounds for failure in this practical and the module examination as a whole.

(Students Handbook 1998-99, page 17)

To be completed by the Departmental Secretary:

SignatureMaterial submittedDate SubmittedHour Submitted

Report

Diskette

Printout(((

To be completed by the Instructor:

Signature & DateSubmitted

MarkMark after oral

(if applicable)

On Time

Delayed((

Other Comments:

CONSULTANCY REPORT AND DATABASE PROJECT PROTOTYPE FOR BELLA PIGNA Ltd.

EXECUTIVE SUMMARY

Modern relational database approach seems to be necessity for every contemporary business firm that intents to remain competitive and successful in todays stiff and more than ever dynamic business environment. To be more concrete, modern Data Base Management System approach, based on the relational database model, emphasizes the importance of the information flow within the organization going from the highest (top management) up to the bottom line (low management level). The cornerstones of each relational database approach are reflected in data integration and information sharing among different end user within the organization. This feature is most striking one and in turn it enables firm to overcome the traditional problems associated with the manual file transaction processing systems. However, to fully exploit advantages of the database approach and especially of the relational database technology, there must be a fundamental shift in the way the information is perceived within the company. If properly applied and adequately developed and designed, such database approach can provide competitive means for a company for it enables the firm to gather relevant and accurate information at many points in the organizational activity chain. Such promptly grabbed information stemming from the various business activities can be used as a competitive weapon and powerful decision-making tool.

TABLE OF CONTENTS

List of Figures and Tables

page 5

Introduction Page

page 6

Current Situation and Business Requirements of Bella Pigna, Ltd.

page 6

Database System Development Project

An Outline of the User

Requirements and Application Domain Description

page 7

Main Body

Preliminary Entity-Relationship (E-R) Model

page 8

Detailed E-R Model (Conceptual Model)

page 9

Logical Database Model

page 10

Physical Design Process and the Database Prototype

page 11

System Navigation Details and Menu Layout

page 12

Conclusions and Recommendations

page 12

Bibliography

page 13

Appendixes

page 14

List of Figures and Tables

Figure 1.0 Preliminary Data Model

page 14

Figure 1.1 Entity CUSTOMER and Attributes

page 14

Figure 1.2 Entity SUPPLIER and Attributes

page 15

Figure 1.3 Entity WINE PRODUCT and Attributes

page 15

Figure 1.4 Entity SHIMPENT, Entity ORDER, and Entity INVOICE

page 16

Figure 1.5 Two User Views of the Entity ORDER for Bella Pigna Ltd.

page 16

Figure 2.1 Main Entity Relationship (E-R) Model

page 17

Table 1.0 Business Objects Identified

page 18

Table 1.1 Schematic Mapping of Entities and Relations

page 19

Introduction

The central theme of this assignment is in fact the creation of the database prototype project for the Bella Pigna Ltd, a small family run firm that deals with wine import trade. The firm intends to replace its existing manual transaction-processing system with a database system and for that reason it has made a closed tender to a number of external database consultancy groups. Therefore, our consultancy group has carried out all necessary preparations and has committed its human and capital resources to generate and submit a unique database solution and proposal. Our database solution includes a complete database system (e.g. relational database prototype) done in Microsoft Access and all accompanying documentation ready for further evaluation by the senior management at Bella Pigna Ltd. Requested material and associated paper documentation will be presented and explained in greater detail in the following text. However, prior to the thorough explanation of the proposed database system, it would be desirable just to briefly note a reader on a situation the firm faces at the present time.

Current Situation and Business Requirements of Bella Pigna Ltd.

Bella Pigna Ltd. currently relies upon the manual transaction processing system whereby underlying business transactions in Sales, Logistics, and Purchasing Department are originated, tracked down, recorded and archived. Moreover, some important business documents are induced by the current manual batch-transaction system and they circulate within the firms departments and within the firm and its customers and suppliers. However, such manually dependent transaction-processing system lacks flexibility to adapt itself to the growing firms business needs and it also fails to provide quick and time-responsive information feedback needed for managers decision making. In addition, given currently installed manual-processing systems seem to be very time consuming to operate, costly and inefficient in their use since they cannot integrate business aspects of all departments into one coherent and flexible processing system. The Information Technology infrastructure employed at the present time at Bella Pigna Ltd, seem rather modest but the firms management expressed obvious desire and intention to improve its existing Information Systems. They have comprehended the strategic importance and relevance of developing and applying new IT tools and techniques aimed at facilitating current and expanding future business horizons. Given the findings and suggestions made by the external Information Consultant, it is therefore advocated that the firm will definitely improve its operational effectiveness and efficiency by applying new Database Management System (DBMS) based on the relational model such is our proposed database solution which details and associated documentation follow. As it will be seen and could be tested the pilot version of our database system satisfies all current business requirements of the Bella Pigna Ltd. and leaves the room for any prospective alternations and amendments. The key feature of the following database system is that it can be relatively easy upgraded and integrated with other compatible database systems in a future as the firm grow and expand its business.

Database System Development Project

An Outline of the User Requirements and Application Domain Description

It has been already ascertained that major business priorities of the Bella Pigna Ltd. reflect the need for time-responsive and accurate information feedback which originates from the cost-effective business transaction environment characterized by the low overhead level and high quality service level. Keeping in mind those business pre-requisites we have made an attempt to design and offer highly flexible, prompt and user-friendly DBMS which relies upon the relational database application executed in Microsoft Access. In fact, our proposed DBMS must not be necessarily implemented in Microsoft Access database application since we have developed a series of unique Entity-Relationship diagrams unified into one Main E-R model which in turn can be implemented in other database applications surrounding (Oracle, etc.). The starting point of our documentation is naturally the outline of the key user requirements and basic database application domain of the respective users. Thus, it has been identified that major user requirements which have to be fulfilled by the database system and which in fact reflect the database application domain description include the following ones:

1. The option and feasibility to create and add new business related data into the database;

2. The option to generate and read relevant business documentation prior, during and after transaction activity (e.g. various reports, invoices, sales orders, sales notifications, purchasing orders, etc.) either in a printed form or on a computer screen;

3. The feasibility of deleting, up-dating and archiving existing business data into the database;

4. Existence of data accuracy, consistency, and security within the database system, and

5. The option of future database integration and adaptation with other Information Systems.

In addition to the above requirements, it is obvious that each department maintains its own file processing system where business transaction records are stored manually and kept separately. However, with the database approach this view is radically altered for within such approach all departments can have the access and share the entire pool of various types of data and information that emanate from different business activities. Hence, a sales manager can instantaneously access not only records and data relating to the sales orders but he/she can access the data pertaining to the product availability or to purchasing order status. In this way, database domain application is further expanded since database approach provides the means for data sharing and information integration.

Main Body

Preliminary Entity-Relationship (E-R) Model

In this step we have identified what are the major business objects and entities that underlie common business transaction at Bella Pigna Ltd. Thus, after we have analyzed the current organizational situation and current information flow among the firm, the firms customers and its suppliers, we have designed the initial preliminary data model as it can be seen in Figure 1.0 (Appendix A, page 14). This preliminary data model in global terms depicts fundamental transaction flow and it identifies several basic business objects, events, or concepts that are involved into the transaction activity e.g. basic data entity types Customer, Sales Order, Invoice, Wine Product, Supplier, Payment. It is important to note that this preliminary data model depicts the relationships between these data entities and it also reveals that all business requirements and logical rules are satisfied and still hold. For instance, this data model implies and reflects that one instance of the data entity Order may contain many instances of the entity Wine product whilst (said in plain language) one wine product may appear on many sales orders. Moreover, it is evident that it replicates the reality of the firms business surrounding and proves the business rule and pre-requisite which holds that different types of wine are supplied by different suppliers (many-to-many relationship).

During this step of the database development process, apart from identifying and graphically depicting basic data entity types and their relationships, we provided some details about other business objects relevant and important in the specific business context of the Bella Pigna Ltd. All those findings have been summarized and presented in table Table 1.0 (Appendix B, page 18) which lists major business objectives (some are hypothetical), the firms organizational units and locations, business functions, entity types and existence of the Information Systems architecture.

Furthermore, the next phase of the database development process involves the creation of graphical diagrams where each data entity type is depicted along with its associated attributes which in turn determine the respective entity type. Thus, in figures 1.1, 1.2, 1.3, and 1.4 (Appendix A, pages 14-16), each relevant entity type is depicted and its identifying properties shown. Typically, at this stage in addition to other entity attributes, a unique attribute or property is generated and assigned a unique value for each respective entity. The purpose of this so-called Primary Key (e.g. shown as the underlined attribute) is to uniquely determine each entity and its relation with other entities, as we shall soon see in the next section. It should be pointed out that entity Wine Product in Figure 1.3, possesses attribute Available which is so-called derived attribute (e.g. shown as dashed ellipse), which implies that it is calculated from specific values or instances of other attributes. By the similar analogy, it can be observed that entity Supplier is featured by the so-called multivalued attribute or property Type of Vignard since it can take on a different values for a given entity instance. Finally, in the same Figure 1.2, it could be encountered a composite attribute type Suppliers Bank that is broken down into component parts.

In addition to this, Figure 1.5 (Appendix A, page 16) schematically depicts two differing views of the same entity type Order. This sub-phase of this preliminary E-R data model or conceptual data model is apparently important since it induces and presents different entity approaches or views that must be synthesized and integrated into one view when generating the main E-R or final conceptual model. Thus, as the Figure 1.5 shows entity Order might be observed and perceived from two distinct user angles in a) from the customers aspect; and in b) from the wine products aspect. By combining and integrating both views into one unified view we can better comprehend the picture of how the transaction activity is executed and actually how the entities relate one to another. After all, it helps us in the subsequent process of schematically mapping the relevant entities and their identifying relations, a mapping process required for the final conceptual data model preparation.

Detailed E-R Model (Conceptual Model)

Having said and explained the preliminary E-R diagrams and figures, we have moved one to the creation of the main Entity-Relationship (E-R) Model as it is shown in Figure 2.1 (Appendix A, page 17). However, before we have reached and designed the entire schematic diagram of the complete E-R model, we prepared schematic mapping of all entities and traced down the initial paths of the relations between them. Thus, as it can be seen in the in Figure 2.1, some new so-called associative entities are introduced and basic relations between entities graphically depicted. The introduction of those associative entity types Order Line and Shipment Line enable us to keep in line with the business rules stressed out by the type of the relationship cardinality and participation. Those specific features and constraints of the relation cardinality and participation specify the nature of the relation and maintain the business rule in effect.

In our case, we have mandatory one-to-optional many cardinality relationship between entities Customer and Order as well as between entities Supplier and Shipment. This means that a customer may submit any number of orders but each order must be submitted by exactly one customer. Here, for the entity Order, the attribute Order ID is a primary key while attribute Customer Code is namely a foreign key. The same analogy holds true for suppliers and shipments, a supplier may send many shipments but each shipment must be sent by exactly one supplier. On the other hand, for each order submitted a customer is billed on with a unique invoice, so we have mandatory one-to-mandatory one cardinality ratio between entities Order and Invoice. In order to preserve our business rule and surmount some problems when expressing the nature of the relationship between entities Order and Wine Product we introduced new so-called associative entity type Order Line with the attributes Order ID, Quantity Ordered and Wine Code. Here the primary attribute is a composite key consisting of attributes Order ID and Wine Code which are in turn the foreign keys for that entity. In this way one sales order, submitted by exactly one customer, may be associated with many wine products ordered. The same analogy is applied when considering entities Supplier, Shipment and Shipment Line in association with the entity Wine Product.

Logical Database Model

The following sequence of the database development process entails the transformation of the previously created conceptual or high-level data model (which is more close to humans and non-understandable to computers) into the logical data model. During this phase conceptual or detailed E-R data diagram is gradually modified into the low-level data model throughout the process of mapping the entities and associated relations. For the sake of mapping those entities and relations between them, Table 1.1 (Appendix B, page 19) is created where each entity and its associated attributes (e.g. along with Primary and Foreign Keys) are depicted in a separate tables. As it can be seen each table is related to particular other table and those relations are mapped and their paths analyzed. This is very helpful and servers as a key guide when the database development process enters the following step of actual physical design of the database prototype in the specific database application tool, in our case, in Microsoft Access.

Physical Design Process and the Database Prototype

Under this step, in its essence, necessary tables are created in the Microsoft Access as being based upon the main E-R data model (Figure 2.1) and corresponding schematic mapping diagram (Table 1.1). Here, each table is actually conceived and constructed given the explicit determination presented in the main E-R diagram and in the schematic map of entities and relations. In fact, for each table we have determined how many columns it would contain, what type of data would be stored in the table (e.g. number, character, currency, date, etc.) and so forth. Indeed, each column has been assigned a name, what data type it would hold, and has been textually described. Moreover, we assign to each table a unique primary key to be a unique integer number (e.g. either auto-number or we assign our own specific integer number). Thus for instance, for a table Wine Product we have unique identification code beginning with the value of 9001 and above whereas for the table Order we use an auto-number option as a unique identifier. This physical design process allows user to set initial parameters and see whether they fit into the existing business transaction environment just by inserting some sample data into tables as we actually did. This is shown by the picture SnapShot1 and SnapShot2 (saved as graphic .jpg files on the disclosed floppy diskette). In this way, by using and populating database with sample data we offer a convenient way to check the accuracy of our initial physical database design, improve communication with the end user, and develop a flexible prototype applications. Any further modifications and adjustments have been undertaken so as to obtain the most optimal database pilot project that satisfies both end user's needs, requests and designer's capabilities.

In addition to this, after the sample data has been inserted and physical database prototype tested, we have continued our work by identifying and creating all underlying relationships between tables. In doing so we paid considerable attention on maintaining a business rules by preserving entity integrity and referential integrity constrain as the picture SnapShots3 depicts. Then on, after initializing the relevant relationships between tables, we wanted to test our sample data by making some simple (one-table) queries or more complex (multi-table) queries. This is clearly depicted in picture SnapShots4 where some useful and goal-oriented queries were generated for the sake of business performance analysis. Such queries opens more room for a greater and detailed sales analysis per product line or per customer (aimed at the sales department needs) or it might give useful insights into the procurement and inventory policy of the purchasing or the logistics department. All in all, quite interesting figures can be calculated and relevant information derived that is necessary for the manager's decision making.

System Navigation Details and Menu Layout

The opening menu window of our database prototype seems to be quite user friendly and it offers the option to be modified and up-graded if needed in the future. Beside basic tables and queries, a prospective end user may chose to insert, up-date or delete data through the form layouts. That is, the forms present more sophisticated way of feeding in and retrieving the data from the database application. Picture SnapShots5 gives some clue how the form looks like and what it can be done when operating into this database mode. For instance, by opening and using form 'Sales Order' or form 'Shipment', end user can easily navigate through it and search for some needed data or other information, or he/she simply can enter new business-transaction data. Finally, in the last section as shown by the picture SnapShot6, some reports about the sales orders, wine record, supplier record, storage record, etc. have been induced and ready for the further analysis and examination.

Conclusions and Recommendations

Given what our disclosed database project-proposal offers, Bella Pigna Ltd. will definitely benefit form the introduction of such relational database system. Advantages of this relational DBMS over traditional manual processing system are quite obvious since the former system surpasses latter one in numerous ways. That is, relational DBMS prototyped in Microsoft Access and disclosed in this consultancy report, can produce quick and time-responsive information feedback, can be easily up-dated and modified, can produce various types of the business-supportive documentation, can assist in the managers decision-making, and provides means for future IT and IS integration. Finally, by applying recent client/server and OLE database approaches the suggested database prototype can be expanded and fully integrated into one overall database system which can serve the needs of all departments in the company.

Bibliography

Bertino, E. & Martino, L. (1993). Object-Oriented Database Systems. Reading, MA: Addison-Wesley, Inc.

Elmesari, R. & Navathe, S.B. (1994). Fundamentals of Database Systems. Redwood City, CA: The Benjamin /Cummings Publishing Company.

McFadden, F.R., Hoffer, J.A. & Prescott, M.B. (1999). Modern Database Management. Reading, MA: The Benjamin /Cummings Publishing Company.

Eaglestone, B. & Ridley, M. (1997). Object Databases. Boston, MA: McGraw-Hill Publishing Company.

Appendixes

Appendix A

Appendix B

Planning ObjectObjects for Bella Pigna Ltd.Does Object Exist in Bella Pigna Ltd Information System Architecture?

ObjectivesIncrease annual salesNo

Exceed sales goals for each wine productNo

Increase sales per same customerNo

Reduce time to fill wine product sales ordersNo

Reduce shipment time for wine productsNo

Increase wine product availability and stock replenishmentNo

Organizational UnitsSales DepartmentYes

Purchasing DepartmentYes

Logistics DepartmentYes

Organizational LocationsRegional Sales OfficesYes

Regional Purchasing OfficesYes

Business FunctionsMarketing and Sales

Order takingYes

Order fulfillmentYes

Sales summarization and notificationYes

Payment and Invoice ReceiptYes

Logistics and Purchasing

Purchasing Order RequisitionYes

Shipment Receive and ArrivalYes

Wine Product Purchasing and Development

Geographical region/product analysisNo

Target market analysisNo

Entity TypesCUSTOMERYes

WINE PRODUCTYes

SUPPLIERYes

ORDERYes

INVOICEYes

SHIPMENTYes

Information SystemsOrder ProcessingNo

Sales ManagementNo

Table 1.0 Business Objects Identified

EMBED Word.Picture.8

317

_1017167605.doc