1)a)

__7__ Normalize the conceptual model.

__3__ Obtain a general description of company operations.

__9__ Load the database.

__4__ Create a description of each system process.

_11__ Test the system.

__6__ Draw a data flow diagram and system flow charts.

__5__ Create a conceptual model, using ER diagrams.

_10__ Create the application programs.

__2__ Interview the mechanics. __8__ Create the file (table) structures.

__1__ Interview the shop manager.

b)

Inventory, Payroll, Work order, and Customer.

A CC rS r ic &R p ir B a ev e ea I fo m tio S ste n r a n y m

In e to y vn r
Pr a ts Prhs g u c a in

Pyo a r ll
E p ye m lo e Pyo a r ll

Wr O d r ok r e
Min n n e a te a c Wr o d r ok r es

C sto e u mr
B g illin P y e ts a mn

The Inventory module will include the Parts and Purchasing sub-modules. The Payroll Module will handle all employee and payroll information. The Work order module keeps track of the car maintenance history and all work orders for maintenance done on a car. The Customer module keeps track of the billing of the work orders to the customers and of the payments received from those customers

c) data dictionary makes it easier to check for the existence of synonyms and homonyms, to check whether all attributes exist to support required reports, to verify appropriate relationship representations, and so on. Therefore, the data dictionary's contents will help us to provide consistency across modules and to evaluate the system's ability to generate the required reports. In addition, the use of the data dictionary facilitates the creation of system documentation

d)

The shop manager needs to consider how the system will be integrated into SILENTs daily workflows. For instance, who will be responsible for administering the system from a business perspective? To leverage the task of entering data into the system, employees should be responsible for logging the maintenance and service activities they perform for specific customers cars during their daily routine. Personnel working the front desk will be responsible for entering customer and sales data. Inventory personnel will be responsible for submitting parts orders through the system. The system should also be integrated with external systems, as much as system integrity allows, to interface with parts suppliers, new servicing recommendations, and customer relations management, so that the data between systems is easily transferred through XML or SOA with minimal transformations for data mapping.

e) The best approach to conceptual database design is to perform an intensive data analysis and requirements gathering, followed by ER modeling, normalization, and data model verification. By focusing on requirements first, the systems analyst ensures that all data needed is in the system. With ER modeling, we ensure that all data in the system is needed

f) Part Failure Rate Report: this report will connect data gathered from the car configuration module and the maintenance modules to identify what parts that fail or require replacement the most. This report will be used by mechanics to educate themselves on common problems that occur on specific vehicle models. This report will also inform managers and engineers of potential design flaws in the vehicles to be corrected with future versions. Customer Relations Management Reports: this set of reports will combine the customer module with their servicing history to identify when customers are due for servicing so that notices may be sent out to them. These reports will also be used by sales representatives and customer relations specialists to identify customer loyalty and gauge customer satisfaction. Employee Skills Matrix: this report will identify what employees have which skills in order to identify who will be the best choice for performing new tasks or serving specific vehicle models. This report will also help management identify weakness in the organization for employee skill sets and ways to consolidate skill sets among employees through training programs and mentoring. Financial Reports: a suit of reports for determining revenues and costs that will be used by managers to determine ways to save money, increase profits. These

reports may also be customized for IRS reporting as well as posting updates to stockholders as required by law.

2)

Basically, all answers to all (relevant) questions help shape the database design. In fact, all information collected during the initial study and all subsequent phases will have an impact on the database design. Keep in mind that the information is collected to establish the entities, attributes, and the relationships among the entities. Specifically, the relationships, connectivities, and cardinalities are shaped by the business rules that are derived from the information collected by the designer. Sample questions and their likely impact on the design might be: Do you want to develop the database for all departments at once, or do you want to design and implement the database for one department at a time? How will the design approach affect the design process? (In other words, assess top-down vs. bottom-up, centralized or decentralized, system scope and boundaries.) Do you want to develop one module at a time, or do you want an integrated system? (Inventory, production, shipping, billing, etc.) Do you want to keep track of the nuts and bolts by lot number, production shift, type, and department? Impact: conceptual and logical database design. Do you want to keep track of the suppliers of each batch of raw material used in the production of the nuts and bolts? Impact: conceptual and logical database design. E-R model. Do you want to keep track of the customers who received the batches of nuts and bolts? Impact: conceptual and logical database design. ER model. What reports will you require, what will be the specific reporting requirements, and to whom will these reports be distributed? The answers to such questions affect the conceptual and logical database design, the databases implementation, its testing, and its subsequent operation.

a. What do you envision the SDLC to be? The SDLCis not a function of the information collected. Regardless of the extent of the design or its specific implementation, the SDLC phases remain: PLANNING Initial assessment Feasibility study

ANALYSIS User requirements Study of existing systems Logical system design DETAILED SYSTEMS DESIGN Detailed system specifications IMPLEMENTATION Coding, testing, debugging Installation, fine-tuning MAINTENANCE Evaluation Maintenance Enhancements b. What do you envision the DBLC to be? As is true for the SDLC, the DBLC is not a function of the kind and extent of the collected information. Thus, the DBLC phases and their activities remain as shown: DATABASE INITIAL STUDY Analyze the company situation Define problems and constraints Define objectives Define scope and boundaries DATABASE DESIGN Create the conceptual design Create the logical design create the physical design IMPLEMENTATION AND LOADING

Install the DBMS Create the database(s) Load or convert the data TESTING AND EVALUATION Test the database Fine-tune the database Evaluate the database and its application programs OPERATION Produce the required information flow MAINTENANCE AND EVOLUTION Introduce changes Make enhancements

3)

The development of an information system will differ in the approach and philosophy used. More precisely, the designer team will probably be formed by a group of system analysts and may decide to use a decentralized approach to database design. Also, as is true for any organization, the system scope and constraints may be very different for different systems. Therefore, designers may opt to use different techniques at different stages. For example, the database initial study phase may include separate studies carried out by separate design teams at several geographically distant locations. Each of the findings of the design teams will later be integrated to identify the main problems, solutions, and opportunities that will guide the design and development of the system.

4)

1. In an educational institute, there are several departments and students belong to one of them. Each department has a unique department number, a name, a location, phone number and is headed by a professor. 2. Professors have a unique employee Id, name, phone number. We like to keep track of the following details regarding students: name, unique roll number, sex,phone number, date of birth, age and one or more email addresses. 3. Students have a local address consisting of the hostel name and the room number. They also have home address consisting of house number, street, city and PIN. It is assumed that all students reside in the hostels. 4. A course taught in a semester of the year is called a section. There can be several sections of the same course in a semester; these are identified by the section number. Each section is taught by a different professor and has its own timings and a room to meet. 5. Students enroll for several sections in a semester. Each course has a name, number of credits and the department that offers it. A course may have other courses as prerequisites i.e, courses to be completed before it can be enrolled in. 6. Professors also undertake research projects. These are sponsored by funding agencies and have a specific start date, end date and amount of money given. More than one professor can be involved in a project. Also a professor may be simultaneously working on several projects. A project has a unique projectId.

Entities -STUDENT

Entities -Department and Course

Entities -Professor, Project and Sections

E/R Diagram showing relationships

ER Diagram of a univrsity / college

5)

Requirements:Consider the operations of a video sales and rental chain. Such a company purchases videos from vendors and stocks them in one of many stores. Each store has several employees who rent or sell these videos to customers. All customers are members of the video chain. Members are required to return rented videos by the due date, otherwise a fine will be imposed. Commissions are awarded to employees based on their sales volume. The database design should include tables for STORE, EMPLOYEES, VIDEOS, MEMBERS, RENTALS, SALES, and VENDORS. You should choose appropriate attributes for these tables and specify constraints. The STORE table records the store numbers and addresses of the individual store. The EMPLOYEES table records information about the employees and the stores they work in. The VIDEOS table contains information about all the videos in the company. It should contain a stock_number attribute to indicate which store the videocassette belongs to. Information about the members is kept in the MEMBERS table. Members are given bonus points every time they rent a video, and accumulated points are recorded in this table. Members are eligible for a free rental after

accumulating a certain number of bonus points (your choice). The RENTALS and SALES tables record transactions. For rentals, the date checked out, the frequency for the checkout (how many days), and the date returned are recorded. The VENDORS table records information about the vendors from whom the videos are purchased. From these requirements, we deduce the following: -all employees are associated with exactly one store -a specific, physical copy of a video may only be owned by one store We will also assume the following while designing this database: -a store may have more than one copy of a movie title -the price of a rental or sale varies based on popularity, newness, etc -each rental gives 2 bonus points; each sale gives 4 bonus points -members are eligible for a free rental after accumulating 10 bonus points -employees receive $0.50 commission for every video sold or rented -movies of the same title do not necessarily come from the same vendor

ENTITY-RELATIONSHIP DESIGN Entity Specification: STORE:

S TORE StoreNo Address Phone

EMPLOYEE:

Clearly, we will need an entity to denote each store in the video chain. Each store will be assigned an identification number. We will also keep record of the stores address and phone number.

We will also need an entity to represent each individual employee who works for the video chain. Each employee shall be assigned a unique identification number. Other relevant information includes the employees Social Security Number (for payroll purposes), their full name, hourly wage, mailing address, phone number, and hiring date. We will also be keeping track of the sales volume of each employee. Each time the employee handles a rental or sales transaction, this attribute will be incremented. From this attribute, we will calculate the employees commission ($0.50 per transaction). This is derived from TransactionVolume and will be computed in the application program, so we do not show it here.

EMPLOY EE EmpNo SSN Name Address Phone Wage TransactionVolume DateHired

VIDEO:

V IDEO VideoID Format

Modeling videos proves a bit ambiguous. When we refer to a video, are we referring to the movie as a work of art, or to a physical copy of a movie? We encounter other design issues if we use only this entity to describe videos.

We of course want to store the title, rating, and runtime of a movie. It is also true that the video chain is likely to have multiple copies of the same movie. Therefore, if we use only this entity to denote both physical copies of the movie and to store other information about the movie, we will end up storing title, rating, and runtime information redundantly for each copy of the movie the chain has. This is, of course, undesirable. If a clerk is processing a shipment and incorrectly types a title after being required to do it eight times for the same movie, we will have an inconsistent database. This is also a tedious waste of the employees time when they could simply link an identification number for a physical cassette/DVD to an identification number in a movie catalog identifying the movie itself. So, we will need to create some way to separate the concept of a physical copy of a movie and the movie as a work of art. For now, we shall indicate that the entity VIDEO refers to a physical copy of a movie, assigning it an identification number. Because it pertains to the physical copy itself, we will also store information on what format the movie is in (i.e. VHS, DVD, Blu-Ray).

CATALOG: Here we address the design issue we ran into when specifying the VIDEO entity. VIDEO V IDEO shall represent a physical movie, whereas VideoID this CATALOG entity will refer to the movie as a work of art. For claritys sake, henceforth, the word video will refer to a physical copy of a movie, and the word movie will refer to the work of art that is stored on a recording medium. We model a movie using the entity CATALOG, so called because the CATALOG table models the movies that are available at the video store to rent or purchase. We will assign each item in the catalog an identification number, a movie title, the genre, a rating (G, PG, PG-13, R, NC-17), runtime (in minutes), format, and a price. We notice that we have now included the format of the product in both the VIDEO and CATALOG entities. There are likely to be different pricings on different formats like VHS, DVD, and Blu-Ray, so I will remove the format attribute from VIDEO and place it in CATALOG instead, since these two entities will be linked by a relationship indicating the format in the CATALOG entity. Finally, CATALOG will contain the rental and sales price for the movie in question.

C ATAL OG CatalogID Title Genre Format Rating Runtime RentalPrice SalesPrice

We do run into another problem here. In the project specification, we are required to list the length of time the movie is rented for. This implies that a customer is able to rent a video for varying lengths of time. Therefore, we cannot set a flat rental price on an item in the catalog because the price depends on the rental period. Let us assume that the business offers 24-hour, three day, and week-long rentals. We will use a new entity and modify the CATALOG entity to handle pricing based on rental period. This has the added benefit of making price changes to multiple movies based on a pricing category that may be based on some parameter such as popularity. To take advantage of that, we will remove both rental and sales prices from the CATALOG inventory and relate CATALOG to a new PRICING entity, described below.

PRICING:

PR ING IC PriceCode SalesPrice DayPrice ThreeDayPrice WeekPrice

This entity corresponds to a pricing policy for a specific type of category of movie. Each pricing category is uniquely identified by a

pricing code. The entity will have information for sales prices, 24-hour rentals, three day rentals, and week long rentals. The benefit of this setup, as mentioned before, is that the company can make overarching changes to the pricing of many movies by altering the charges in that pricing category. Changing each and every item in the catalog by comparison is tedious and may lead to inconsistency.

To summarize, we now have the following for VIDEO, CATALOG, and PRICING to describe our inventory of videos. They will be linked through relationships. VENDOR:

V IDEO VideoID

C ATALOG CatalogID Title Genre Format Rating Runtime

PR ING IC PriceCode SalesPrice DayPrice ThreeDayPrice WeekPrice

V END OR VendorID Name Address Phone

Clearly, the video chain needs to obtain their inventory from a supplier. We model these suppliers using the VENDOR entity. Each vendor will be assigned an identification number, will have a name, address, and phone number.

MEMBER:

MEMB ER MemberID Name Address Phone JoinDate BonusPoints

Now we model the customers, or members, of the video chain. Each customer will be assigned a membership ID number. We will also record their name, address, phone number, the date the member joined, and the members accumulated bonus points.

RENTAL: Here we model the primary type of transaction at the store, a rental of a video. We will record the date the video was checked out, the length of the rental period, and the date the video was returned. We will also keep track of the transaction amount (including what we will assume to be a 6% tax) and any additional late fee assessed, if applicable. The late fee will be entered as $0.00, not null, if the video is returned on time. If the MEMBER has 10 bonus points at the time, then the transaction amount will be zero.

RENTAL DateRented DaysRented ReturnDate TransactionAmount LateFee

RENTAL will be a weak entity set; VIDEO will be its identifying entity set. DateRented will be the discrimator because it is impossible for a movie to be rented more than once on the same day. SALE:

S ALE DateSold TransactionAmount

Finally, we model a sale of a video. We will record the date the video was sold and the transaction amount (including a 6% sales tax). SALE is a weak entity set; VIDEO is its identifying entity set. E-R Diagram:

S TOR E S toreNo Address Phone

works_at

handles

EMPLOY EE EmpNo SN S Name Address Phone Wage TransactionVolume DateHired

rented stocks S E AL DateSold TransactionAmount sold V EO ID VideoID describes buys

handles

R ENTAL DateRented DaysRented ReturnDate TransactionAmount LateFee

rents

purchased_from C ATAL OG CatalogID Title Genre Format Rating Runtime

MEMB ER MemberID Name Address Phone JoinDate BonusPoints

V END OR VendorID Name Address Phone

prices

PR ING IC PriceCode S alesPrice DayPrice ThreeDayPrice WeekPrice