welcome to idbs center innovative data base solutions presents: comat auto service project project...

Welcome to IDBS CenterWelcome to IDBS Center

Innovative Data Base Solutions presents:

Comat Auto Service Project

Project Manager: Emanuela Cerchez

REFERENCES REFERENCES

Innovative Data Base Solutions :: Comat Auto Service :: Innovative Data Base Solutions :: Comat Auto Service ::

• Interview with mr. Valeriu Sarbusca, manager of Comat Auto Service

Address: Str. Serg. Grigore Ioan, no. 7, Iasi, RomaniaPhone number: +40232.241.000 Fax: +40232.240.699

• Websites referring to similar business:

http://www.jiffylube.com/http://datsonville.alldatashop.com/

http://www.jiffylube.com/



http://datsonville.alldatashop.com/





BUSINESS DESCRIPTION BUSINESS DESCRIPTION


• Comat Auto Service provides services for Daewoo car models. They have a special license which allows them to provide certificated mechanical treatments and company warranties. • Working with such a company gives them the opportunity to obtain original car parts, directly from the company’s factories.• Because they work with many clients, some of them owners of more than one car (e.g. Taxi Companies) they need a way to keep track of their employees, clients, repaired cars, jobs done, warranties offered, and many more.

PROPOSED SOLUTION PROPOSED SOLUTION


We offer them the solution they need, that consists in an optimized database model, which is the base for further applications development.

BUSINESS NEEDS BUSINESS NEEDS


• Comat Auto Service needs to hold details about their clients like: full name, phone number, address, an optional e-mail address and, only if the client is a firm, the fiscal code, account number. • A client can make appointments and the service needs to hold the appointments’ dates.• They need to hold information about their clients’ cars that were repaired, what was repaired (the labor and parts used for the rapairs) and the issued bills. • They also need to keep track of the parts they have in their storehouse.

BUSINESS NEEDS BUSINESS NEEDS


• The service needs to hold historical information such as: bills paid and issued over time and also information that modifies over time such as: price per hour of labor, price per km of transport, salaries paid for an employee (salaries and bonus-payments/penalties) and time-offs taken by these.• About its employees the service needs to know their CNP (the correspondent of Social Security Number), full name, phone number, address and job description. For its mechanics the service must keep track of worked hours.

FIRST INTERVIEW – INTIAL ERD FIRST INTERVIEW – INTIAL ERD


Four main areas of interest for the service were identified after the interview: the center with its employees, the clients with their cars, jobs done for cars and the parts in the service’s storehouse.

Therefore we modeled an initial ERD to include this four areas of interest (separated by position and color).

INITIAL ERD INITIAL ERD


INITIAL ERD – STRUCTURAL RULES INITIAL ERD – STRUCTURAL RULES


• For the center we retained: name (name followed by city), which is its unique identifier, phone number, address, support phone number, website.• For the employees we retained as mandatory attributes: cnp, first name, last name, phone number, address, number of days off (maximum number of days off an employee could take in one year – specified in his employment contract) and as optional attributes: e-mail and special notes.• The cnp attribute of employee composed with the center’s id (name) form the employee’s entity unique identifier.



• For clients we retained as mandatory attributes: id (unique identifier), first name, last name, phone number, address and as optional attributes: e-mail and special notes (general description of the client).• For cars: we retained: registration number, chassis number, model, color (standard code that corresponds to the color of the car) and as optional attribute special notes.• The registration number and the chassis number attributes of car entity, together with client’s id attribute form the car’s entity unique identifier.• For job’s we retain: bill code, price and warranty (number of days the job is guaranteed).



• The job’s unique identifier is formed of the bill code attribute together with the car’s unique identifier (registration number, chassis number plus the client’s id).• For parts we retain: id (unique identifier), name, special notes (optional).

INITIAL ERD – STRUCTURAL RULES – RELATIONSHIPS INITIAL ERD – STRUCTURAL RULES – RELATIONSHIPS


• The center must be the employer of one or more employees.• Each employee must be employed by one and only one center.• The center must be the owner of one or more parts.• Each part must be owned by one and only one center.• Each part may be used in one ore more jobs. • Each job may use one ore more parts.• Each job must be for one ore more cars.• Each car must have one ore more jobs.• Each client must be the owner of one ore more cars.• Each car must be owned by one and only one client.

CLOSER ANALYSIS CLOSER ANALYSIS


While we were documenting all the business rules we started getting a better idea about the business and its complexity. We started from the Initial ERD and we identified other entities and relationships.We noticed that the whole business works around those four areas of interest identified earlier so we modeled our ERD piece by piece, reuniting them at the end in the Final ERD.

Next we will present you, in detail, the four Partial ERDs modeled by us.

FIRST PARTIAL ERD – NEEDS FIRST PARTIAL ERD – NEEDS


The main new entities found and modeled in the First PartialERD are: center, hour price, due, employee, salary, timeoff, extra payment. In modeling this first part of thebusiness we needed to take into account questions like:• Can we track the employee’s salary modifications overtime?• Can an employee be rewarded with prizes for his work?• Can we track the evolution of the price per hour practiced?• Can we find out the service’s expenses for a certainperiod of time?• How can we obtain an employee classification dependingof their specialization?and many more.

FIRST PARTIAL ERD FIRST PARTIAL ERD


FIRST PARTIAL ERD – STRUCTURAL RULES FIRST PARTIAL ERD – STRUCTURAL RULES


• Like in the Initial ERD, for the center entity we retained:name, which is its unique identifier, phone number,address, support phone number, website.• For the hour price entity, which models price per hour oflabor modifications over time, we retained: start date (thedate when we started using that price) and price.• The start date attribute, together with the center’s id(name) forms the hour price’s entity unique identifier.• For the due entity, which represents the bills that the AutoService has to pay to other services providers (e.g.electricity, water), we retained: bill code (unique identifier)and date (the date when the bill was issued by theproviders).



• We added three subtypes to the initial employee entity,which make the difference between different types ofemployees, identified by the employee entity’s uniqueidentifier (cnp). For the engineer subtype we retained:specialization, for the mechanic: id (another uniqueidentifier besides the employee’s id - cnp) and domain (ofactivity) and for the other subtype: job description.• For the salary entity we retained: start date, value and anoptional attribute description (contains eventualexplanations).• The start date attribute of the salary entity together withthe employee entity’s id (cnp) form the salary entity’sunique identifier.



• For the extra payment we retained: date (the date when itwas given) and the value (if positive it represents an extrapayment and if negative it represents a penalty).• The occasion entity is an intersection entity resolving the“many to many” relationship between employee and extrapayment. We retain for it an attribute description containingthe description of the occasion the extra payment/penaltywas given. Its unique identifier comes from the combinationof the employee id (cnp) and the extra payment id (date).• For the time off entity we retained: start date, an optionalend date.



• An employee could be either an engineer or mechanic orother (office staff or maintenance staff). • We don’t need an end date attribute in the hour priceentity because there is no period of time when a pricedoesn’t exist. So the start date for the following price willrepresent the end date for the current price. • The employee’s salary can change over time.• For the engineer and other types of employees thesalary (plus eventual extra payments/penalties) representsthe whole payment but for the mechanic we must add thecost of the hours of labor he has (hours of labor times priceper hour of labor at the time he worked them).



• When an employee is fired or he quits, a new salary withthe value zero will be created for him and the special noteswill contain “fired” or “quit”. • An employee can be extra paid or penalized.• We can’t make more than one extra payment at the exactsame time for the same employee.• We don’t need an end date attribute in the salary entitybecause there is no period of time when an employeedoesn’t have a salary. The start date for the following salaryvalue will represent the end date for the current salary value.• The date attribute everywhere in the project contains year,month, day, hour, minute and second.

FIRST PARTIAL ERD – STRUCTURAL RULES – RELATIONSHIPS FIRST PARTIAL ERD – STRUCTURAL RULES – RELATIONSHIPS


• The center must practice one ore more hour prices.• Each hour price must be used by the center.• The center must pay one or more dues.• Each due must be paid by the center.• The center must be the employer of one or moreemployees.• Each employee must be employed by the center.• Each employee must be paid with one or more salaries(over time).

FIRST PARTIAL ERD – STRUCTURAL RULES – RELATIONSHIPS FIRST PARTIAL ERD – STRUCTURAL RULES – RELATIONSHIPS


• Each salary must be for one and only one employee.• Each employee may have one or more occasions• Each occasion must be for one and only one employee.• Each occasion must be for one and only one extrapayment.• Each extra payment must have one or more occasions.• Each employee may take one or more time offs.• Each time off must be for one and only one employee.

SECOND PARTIAL ERD – NEEDS SECOND PARTIAL ERD – NEEDS


The main new entities found and modeled in the SecondPartial ERD are: client, appointment, account, car. Inmodeling this part of the business we needed to take intoaccount questions like:

• Can we know if a client has any appointments?• Can we find out how a bill was paid?

SECOND PARTIAL ERD SECOND PARTIAL ERD


SECOND PARTIAL ERD – STRUCTURAL RULES SECOND PARTIAL ERD – STRUCTURAL RULES


• For the client entity we retained as mandatory attributes:id (represented by an unique code which is assigned foreach client), first name, last name, phone number, addressand as optional attributes: e-mail and fiscal code (fiscalcode will be filled in only if the client is a firm).• For each appointment a client may make, we retainas mandatory attributes: appointment date (the date of theappointment) which together with the client’s id form theentity’s unique identifier, and as optional attribute:description (a possible description of the client’s problem).



• For the account entity we retained as mandatoryattributes: account number and bank (the bank which holdsthe account) which combined represent the entity’s uniqueidentifier. • Like in the Initial ERD, for cars we retained: registrationnumber, chassis number, model, color and as optionalattribute special notes (short description). The registrationnumber and the chassis number attributes of car entity,together with client’s id attribute form the car’s entityunique identifier.



• A bill can be paid either with cash or using an account.If the bill is in relation with an account that bill was paidwith that account. If a bill doesn’t have any relation withany account, the bill was paid with cash.• When a new client is created a code will be generated forhis id attribute.• If a car changes its registration number or its owner it willbe stored as another car in the database.• The mandatory attribute color of car’s entity represents astandard code that corresponds to the color of the car.

SECONDSECOND PARTIAL ERD – STRUCTURAL RULES – RELATIONSHIPS PARTIAL ERD – STRUCTURAL RULES – RELATIONSHIPS


• Each client may have one or more appointments.• Each appointment must be for one and only one client.• Each client may be the owner of one or more accounts.• Each account must be owned by one and only oneclient. An account cannot be transferred to another client(the relationship is non-transferable).• Each client must be the owner of one or more cars.• Each car must be owned by one and only one client.• An account may pay one or more bills.• A bill may be paid with an account.

THIRD PARTIAL ERD – NEEDS THIRD PARTIAL ERD – NEEDS


The main new entities found and modeled in the ThirdPartial ERD are: bill, job, transport car, transport price.In modeling this part of the business we needed to take intoaccount questions like:

• Can we find out the mechanics that were involved in ajob?• Can we find out what jobs were done on a car?• Could we know how many hours a mechanic had workedin a month?• Can we know if a job is still in its warranty period?

THIRD PARTIAL ERD THIRD PARTIAL ERD


THIRD PARTIAL ERD – STRUCTURAL RULES THIRD PARTIAL ERD – STRUCTURAL RULES


• For the bill entity we retained as mandatory attributes: billcode (unique identifier), date and as optional attribute: description.• For the job entity (the total work of an employee for a car,at a certain visit to the service), we retained as mandatoryattributes: number of hours (of labor) and warranty. Thisintersection entity’s unique identifier is composed of themechanic’s id and the bill’s id (bill code). This entityresolves the problem with the “many to many” relationshipbetween employee and bill.



• For the transport task intersection entity (resolving the “many to many” relationship between bill and transport car) we retained as mandatory attributes: pick up hour (the hour the client was picked up). This attribute together with the bill code and the transport car id gives us the unique identifier for the transport task entity. We also retained as an optional attribute a description (short description of the route followed).• For the transport car entity we retained mandatory attributes as: id (internal unique code), registration number, model and also an optional attribute description (e.g. condition, type of combustion).



• For the transport price entity we retained mandatory attributes as: start date, which together with the transportcar’s id forms the entity’s unique identifier, and also value.• The price may differ from a transport car to another.• The transport car’s id represents a unique internal code allocated by the service for a easier identification.

THIRD PARTIAL ERD – STRUCTURAL RULES – RELATIONSHIPS THIRD PARTIAL ERD – STRUCTURAL RULES – RELATIONSHIPS


• Each car must have one or more bills.• Each bill must be for one and only one car. An issued bill cannot be transferred for another car (the relationship is non-transferable).• Each mechanic may do one or more jobs.• Each job must be done by one and only one mechanic.• Each job must be on one and only one bill.• Each bill may contain one or more jobs.

THIRD PARTIAL ERD – STRUCTURAL RULES – RELATIONSHIPS THIRD PARTIAL ERD – STRUCTURAL RULES – RELATIONSHIPS


• Each bill may contain one or more transport tasks.• Each transport task must appear on one and only one bill.• A transport task must be done by one and only one transport car.• A transport car may do one or more transport tasks.• Each transport car must have one or more transport prices.• Each transport price must be for one and only one transport car.

FOURTH PARTIAL ERD – NEEDS FOURTH PARTIAL ERD – NEEDS


The main new entities found and modeled in the FourthPartial ERD are: part type, part group, acquisition, loss.In modeling this part of the business we needed to take intoaccount questions like:

• Can we find out at a certain moment how many parts ofthe same type are in the warehouse?• Can we find out how many losses the service had in amonth?• Can we find out what parts were used for a job?

FOURTH PARTIAL ERD FOURTH PARTIAL ERD


FOURTH PARTIAL ERD – STRUCTURAL RULES FOURTH PARTIAL ERD – STRUCTURAL RULES


• For the part group entity we retained: provider’s price,which, together with the acquisition’s id (bill code) andpart type’s id forms the entity’s unique identifier, we alsoretained addition (a percent of the provider’s price), initialnumber (initial number of parts in that group), and anoptional attribute special notes (e.g. quality of the parts inthat group).• For the acquisition entity we retained: bill code (the bill’scode with which the part group was bought, which is alsothe unique identifier of this entity) and date (the day thetransaction was made).



• For the loss entity (an entity that tells us the losses, likebroken or lost parts) we retained: date (of the loss, which,combined with the part group id gives us the uniqueidentifier for this entity) and value (the number of parts lostor broken).• For the quantity entity (an intersection entity which,besides resolving a “many to many” relationship, tells ushow many parts from one group were used for a job) weretained only value (the number of used parts); this entity’sunique identifier is formed of the bill’s id and the partgroup’s id.



• For the part type entity we retained: id (its catalognumber if the part is produced by Daewoo factories, or else, a uniquely generated code), name and, as an optional attribute, special notes (short description of the part type).• As in the initial ERD, for the center we retained: name (name followed by city), which is its unique identifier, phone number, address, support phone number, website.

FOURTH PARTIAL ERD – STRUCTURAL RULES – RELATIONSHIPS FOURTH PARTIAL ERD – STRUCTURAL RULES – RELATIONSHIPS


• The center must be the owner of one or more part types.• Each part type must be owned by the center.• Each part type must have one or more part groups.• Each part group must be contained in one and only one part type.• Each part group must be on one and only one acquisition.• Each acquisition must be for one or more part groups.

FOURTH PARTIAL ERD – STRUCTURAL RULES – RELATIONSHIPS FOURTH PARTIAL ERD – STRUCTURAL RULES – RELATIONSHIPS


• Each part group may have one or more losses.• Each loss must be for one and only one part group.• Each part group may have one or more quantities.• Each quantity must be for one and only one part group.• Each quantity must be for one and only one bill.• Each bill may contain one or more quantities.

FINAL ERD – STRUCTURAL RULES FINAL ERD – STRUCTURAL RULES


We modeled all the entities that the business needed in thePartial ERDs and then we had to bring them together justlike in a puzzle (you can see the 4 regions of the ERDrepresenting different modules – different colors).Most of the business rules were found during the modeling ofthe Partial ERDs. We have to mention a few proceduralrules that we found, rules that couldn’t be modeled.A single relationship wasn’t described during the partialmodeling:

• The center may be the owner of one or more transportcars. • Each transport car must be owned by the center.

FINAL ERD – PROCEDURAL RULES FINAL ERD – PROCEDURAL RULES


• A client who has an appointment has priority in front of the other clients.• Only mechanics are authorized to make manual labors.• The final price of a part is the sum of provider’s price and addition percent.• The total cost of a bill is the sum of the final prices of all pieces used in that bill, the total number of labor hours times the cost per hour of labour and, if the car was transported to the service with a transport car, the number of km of transportation times the price per km (depending on the transport car).

FINAL ERD – PROCEDURAL RULES FINAL ERD – PROCEDURAL RULES


• The end date attribute of the time off entity will becompleted when the employee returns from vacation andthe payment for the vacation is calculated before theemployee takes time off.

FINAL ERD – PROGRAMMATIC RULES FINAL ERD – PROGRAMMATIC RULES


• The attribute value, from quantity entity, must be bigger than zero.• The attribute addition of the part group entity will contain a positive number, representing a percentage of the provider price.• A part group will be empty when the sum of all the parts lost plus the sum of all the parts used from that group equals the initial number (the sum of all the parts lost plus the sum of all the parts used from that group can’t be bigger than the initial number).

FINAL ERD FINAL ERD


ASSUMPTION – CONSTRAINT ASSUMPTION – CONSTRAINT


• Assumption:

We assumed that this business will extend in time and willhave more than one center.

• Constraint:

In the time off entity, the start date must always be anearlier date than the end date.

FINAL ERD – EXAMPLES FINAL ERD – EXAMPLES


Here are some examples of documents that can result from this model:

Number of worked hours for: Employee No. 3 23 – 26 / 09 / 2004

No. Date Car No. of hours Description 01 09/23/04 IS-10-FXY 2 Exhaust 02 09/23/04 IS-99-XSF 2.4 Engine 03 09/24/04 IS-78-TYU 1 Door panel 04 09/24/04 IS-89-TTT 1.4 Revision 05 09/24/04 B-87-UIO 4 Brakes 06 09/25/04 GL-01-BBB 2.3 Engine 07 09/25/04 IS-14-AIZ 2 LPG 08 09/25/04 IS-09-JHN 2 LPG 09 09/26/04 IS-12-UYI 1 Lights 10 09/26/04 IS-12-UYI 1,5 Brakes

TOTAL 19.6

FINAL ERD – EXAMPLES FINAL ERD – EXAMPLES


Appointments Date: 11/23/04

No. Client Name Hour Notes 1 John Smith 8:00 Engine problems 2 Becalli Andreeas 10:00 Replace mirror 3 Aaron Camden 10:30 Exhaust system 4 Mary Anderson 10:30 Body 5 Bob Thorn 12:15 Brakes 6 Fred Lee 14:00 Engine problems

Transport tasks Date: 10/15/04

No. Client Name Pick up hour Description 1 John Smith 10:00 Downtown 2 Becalli Andreeas 10:00 East exit 3 Aaron Camden 12:30 Mall 4 Mary Anderson 11:30 Main Park 5 Bob Thorn 12:15 21 St. 6 Fred Lee 11:00 Mall

Thank you for your attention.Thank you for your attention.

Our solution is the best choice our client could make because it solves all the managerial problems, saving time and money for the business.

Innovating your business…Innovating your business…

IDBS:

Bogdan Cernea

Ovidiu Sarbanescu

Alexandru Sarbusca

Ioan Orzetic

Bogdan, Ovidiu, Alex and Ionut

Liceul de Informatica Grigore C. Moisil Iasi, Romania

welcome to idbs center innovative data base solutions presents: comat auto service project project...

Documents

comat auto service needs

clients cars

support phone number

romania phone number

account number

emanuela cerchez slide

repaired cars

original car parts