Sunteți pe pagina 1din 51

Data Analyzing and Designing

Data Analyzing and Designing

Data Analyzing and Designing

Data Analyzing and Designing

Acknowledgement
As I, write this report, strongly feel that I must take the opportunity to record my deep appreciation of tender my sincere gratitude goes to our lecturer Mr. Kithsiri Jayakody who provided me with guidance, support and constructive suggestions that contributed immensely for the successful completion of this assignment. I must also convey my heartiest thanks to staff of the IT Section, who sacrificed their valuable time to help us to complete our undertaking successfully. Finally I wish to express my gratitude to my parents and friends for the encouragement given me. Thank you, A.L.M.Ameen.

Data Analyzing and Designing

Contents
Pages Grading Criteria Acknowledgement Contents Introduction Task 01 1.1 Contrasting database models 1.2 Entities and Attributes 1.3 Data dictionaries 1.4 E-R diagram 1.5 Normalization Task 02 3.1 Proper database type for the scenario ant its implementation 3.2 Relationship Diagram 3.3 Constraints and Integrities Task 03 3.1 Store procedures 3.2 SQL Quarries 3.3 Store procedures 3.4 Triggers 3.5 Views 3.6 SQL Quarries Task 04 4.1 Creating Indexes 4.2 Maintenance Plan 4.3 Data warehouse 4.4 Connect the SQL server with Visual Studio Conclusion References 1-3 4 5-8 9

10-12 13-15 16-18 19 20-24 25 26 27 28 29 29 29 29 30 31-32 33-36 37 38-40 41 41

Data Analyzing and Designing

Figures
Task-01 Figure Figure Figure Figure 1.1.1 1.1.2 1.1.3 1.1.4 . . ..... . Page No 9 9 10 10

Figure 1.4

. 18

Figure 1.5.1 . 20 Figure 1.5.2 . 21 Figure 1.5.3 . 22 Task-02 Figure 2.2 Task-04 Figure 4.1.1 . 30 Figure 4.1.2 ..... 31 Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 4.2.7 4.2.8 4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 . . . ..... . . . ..... . . . ..... . 32 32 33 33 34 34 35 35 37 37 38 38 39 . 25

Data Analyzing and Designing

Tables
Task-01 Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 1.2.6 1.2.7 1.2.8 1.2.9 1.2.10 1.2.11 1.2.12 1.2.13 1.2.14 1.2.15 1.2.16 1.2.17 1.2.18 1.2.19 1.2.20 1.2.21 1.2.22 Page No . 12 . 12 ..... 12 . 12 . 12 . 12 . 12 . 12 . 12 . . . 13 . 13 ..... 13 . 13 . 13 . 13 . 13 . . 13 . .

12 12

13 13 13

1.2.23 . 14 1.2.24 . 14 1.2.25 . 1.2.26 .14

14

Table 1.3.1 . 15 Table 1.3.2 . 16 Table 1.3.3 .17 Table Table Table Table Table Table Table Table Table Table Table 1.5.1 1.5.2 1.5.3 1.5.4 1.5.5 1.5.6 1.5.7 1.5.8 1.5.9 1.5.10 1.5.11 . 23 . 23 ..... 23 . 23 . 23 . 23 . 23 . 23 . 23 . .

23 23

Data Analyzing and Designing

Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table

1.5.12 1.5.13 1.5.14 1.5.15 1.5.16 1.5.17 1.5.18 1.5.19 1.5.20 1.5.21 1.5.22

. 23 . 23 ..... 23 . 23 . 23 . 23 . 23 . . 23 . .

23 23 23

1.5.23 . 23 1.5.24 . 23 1.5.25 . 1.5.26 .23

23

Data Analyzing and Designing

Introduction
KANDY Pharmacy All drugs are entered by itemID to allow the unique identification of each drug, per drug code. Information regarding the generic and brand name of drug, the supplier and expiry date are all recorded on the system along with the itemID. Search can be done either by name or by itemID to facilitate selection, to view suppliers, keep track of items in shortage, and to find items provided by a given supplier and/or the supplier in relation to a specific item. Furthermore, the system favors a rapid identification of expiry dates of medicaments during a specified period the user opts for. etc In KANDY PHARMACY there are so many transaction functions like I mention above. So they need a sufficient database for maintain those functions. So I did this assignment as a solution for KANDY PHARMACY. In this documentation there are relationship diagram on page number 26,it maybe not clear for you, thing is this I have to save this diagram in application but unfortunately my MS SQL didnt support to save thats why I put it as a printed material. When you see it if you face any troubles , Im asking apology.

Data Analyzing and Designing

Task-01
1.1 What is the Database?
Database is a structured object. It can be a pile of papers, but most in the modern world it exists on a computer system. That structured object consists of data and metadata. Metadata is structured part. Data in a database is the actual stored descriptive information, such as all the names and addresses of your customers. Metadata describes the structure applied by the database to the customer data.

In other words, the metadata is the customer table definition. The customer table definition contains the fields for the names and addresses, the lengths of each of those fields, and data types. (A data type controls values in fields, such as allowing only a date, or a number). Metadata applies structure and organization to raw data.

Understanding database model.


There are many explanations to understand what exactly a database model or data model is. A database model can be used to describe an organized and ordered set of information 10

Data Analyzing and Designing stored on a computer. This ordered set of data is often structured using a data modeling solution in such a way to make the retrieval of data and changes to that data more efficient. Depending on the type of applications using the database, the database structure can be modified to allow for efficient changes to that data.

Comparison of the Hierarchical, Network and Relational, Database Models


Hierarchical Database Model
The hierarchical model is the oldest of the three

models. This model is an improvement of the flat-file database system. The relationships in the hierarchical model are child/parent relationships. The name hierarchical is come from one major restriction on the child/parent relationships that is, a parent entity can have several child entities, a child entity can only have one and only one parent. For this reason all the relationships form a hierarchy that traces back to one root. In fact, this model is often visualized as an upside down tree, where the entity at the top is seen as a root and all other entities sprout from the root. One major problem with the hierarchical model is the increased risk of data changeability. Another problem with the hierarchical model is the inflexibility of the model. Another problem with the hierarchical model is in the child/parent relationship restriction. Every child must have a parent. it is impossible to add new data in a table. To overcome some of the limitations of the hierarchical model, the network model was created.

Network Database Model


The network model is an improvement the hierarchical model. In the network model, a child entity can have more than one parent. Therefore, the design can be visualized as several inverted trees interconnected by branches as opposed to the single inverted tree characteristic of the hierarchical model. Data in the network model can be accessed from an entity as opposed to the hierarchical model that requires access from the root entity. The relationships between entities occur through unique set structures. Therefore, although the entities are not duplicated, a unique set structure is required to facilitate each of the one-tomany relationships. Like the hierarchical model, the network model is also navigational. This deal a big problem in complex designs since the user has to understand the database structure in order to us 11

Data Analyzing and Designing the database. Furthermore, with a predefined structure like in the hierarchical model, modifying the structure of the database becomes a difficult task. The relational model eliminates many of the problems presented in the network and hierarchical models.

Relational Database Model


The relational model is based on the mathematical set theory. In this model, data is stored in relations which are perceived by the user as relations. Relations are made up of tuples (also referred to as records or rows) and attributes (also known as fields or columns). Each record is identified by a column with a unique value. The order of the rows and columns is of importance. Therefore, the relational model is independent of physical implementation, a quality that makes this model more preferable to the hierarchical and database models. Relationships in this model can be one-to-one, one-to-many, or many-to-many. Regardless of the type of relationship, the model is transparent to the user, that is, the user does not need to understand the physical structure of the database in order to use it.

Relational databases also have their share of problems. The flexibility of the relational model comes with the price of performance speed since the relationships are not predefined like in the case of hierarchical and network databases. Flexibility, also introduces the complexity of enforcing integrity constraints. However, the existence of scientific rules for imposing integrity guarantees that database integrity can be ensured.

12

Data Analyzing and Designing

1.2

Drugs
In this drug entity have some attributes. If we see through those

attribute, drug Id used to identify each drugs uniquely. By drug name attribute we can identify a particular drugs commercial name and also by drug generic we can identify drugs scientific name. There are other three attributes that quantity, discount and unit price, those

13

Data Analyzing and Designing three are mostly use in transaction of drugs and quantity attribute want to manage stock details.

Drug Indications

We have to explain to patient how to use drugs when they buy it. It means we have to put those details in receipt for do that this drug Indication attribute is important one.

Prescription

In this prescription entity there is prescriptionID attribute to identify each prescription is uniquely. There are three name attributes one of them is nameOfPatient who get consulting and nameOfPhysicians who give prescription to patient. Other one is nameOfPharmacist who give drugs to patient. So keep those details we want to attributes which I point out above.

Branch
KANDY Pharmacy have many branches. To maintain branches details, branchs stocks and to maintain transactions between branches and people we want to an entity and some attributes that is branch entity.

Patients

14

Data Analyzing and Designing KANDY Pharmacys main target

group is their customers. We may can say everything are happen for the customers and everything depends on customer it mean patients so patents details are very important for KANDY pharmacys system. patintBranch attribute say that which patient buy drugs from which branch. Other attributes are usually.

Invoice

Invoice is a legal document which is say we left from loans. In this invoice entity there is InvoiceID attribute to identify each Invoice is uniquely. By supplierID, you can identify who supply a particular drug. By quantity you can say how much drugs given to pharmacy by a particular supplier. Here inviceDate used to know which day these transactions happen.

Suppliers

15

Data Analyzing and Designing Which supplier supplies which drug and to which branch to know like those details, and to contact again a particular supplier when stock things finished supplier details are important. To do those things Supplier entity will help.

Pharmacist

Pharmacists directly interact with patients, receipts and drugs. They involve every transaction. So their information is very important to do usual works in KANDY Pharmacy.

Receipts

When a patient or customer buys some drugs we must give receipts for them to be sure finance matters. If customers have receipt, they can return or change drugs which they bought. In this invoice entity there is receiptID attribute to identify each receipt is uniquely. By amount, you can identify total price of drugs which a particular customer bought. By quantity you can say how much drugs sale for a particular customer.

16

Data Analyzing and Designing

Receipt _Return / Receipt_ReturnDrug

If a patient or one of customers returns drugs due to any reasons we have to manage those details for do that here are two entities that receipt_returnID and returnID. Amount attribute is for count how much money they paid for that drugs.

Supplier_Return / supplier_treturnDrug
If one supplier supply wrong drugs or same

drugs which still in stock pharmacy have to return it. To do those transaction supplier_return entity have to use.

17

Data Analyzing and Designing

1.3
Table Name Branch Columns Name branchID branchName branchAddress Columns Type Number Text Text Data Type Tinyint Nvarchar(50) Navrchar(75) Columns Status Primary Key Null Null Others Not null

Drugs

drugID drugName drugQuantity unitPrice drugDiscount drugGentric

Number Text Number Number Number Text

Tinyint Nvarchar(50) Int Tinyint Float Nvarchar(100 )

Primary Key Null Null Null Null Null

Drug Indication

drugID Indication of usage

Number Text

Tinyint Nvarchar(100 )

Primary Key Primary Key

Not null Not null

Invoice

invoiceID inviceDate

Number Date/time

Tinyint Date

Primary Key Null

Not null

18

Data Analyzing and Designing brancID number tinyint Null Foreign key

Patient

patientID patientName patientAddress branchId

Number Text Text number Number Number

tinyint Nvarchar(50) Nvarchar(50) tinyint Tinyint Nvarchar(30)

Primary Key Null Null null Primary Key Primary Key

notnull Not null

Foreign key Not null Not null

PatientContNo

patientID patientContNo

Pharmacist

pharmacistID pharmacistName pharmacistAdrress branchID

Number Text Text Text

Tinyint Nvarchar(50) Navrchar(50) tinyint

Primary Key Null Null Null

Not null

Foreign key

PharmacistConNo pharmacistID contactNo

Number Number

Tinyint Nvarchar(50)

Primary Key Primary Key

Not null Not null

Prescription

prescriptionID nameOfThePatient nameOfPharmacist nameOfPhsician patientID

Number Text Text Text number

Tinyint Nvarchar(75) Nvarchar(75) Nvarchar(75 tinyint

Primary Key Null Null Null null

Not null

Foreign key

Table Name Receipt

Columns Name receiptID

Columns Type Number

Data Type Tinyint

Columns Status Primary

Others Not null 19

Data Analyzing and Designing key amount balance quantity branchID patientID PrescriptionID PharmacistID Number Number number number number number number Int Float int Tinyint tinyint tinyint tinyint Null Null Null Null Null null null Foreign key Foreign key

Receipt_Drug

receiptID drugID quantity unitprice

Number number Number Tinyint

Tinyint Tinyint Int

Primary key Primary key Null null

Not null Not null

Receipt_Return

receipt_returnID dates amuont receiptID

Number Number Number Number

Tinyint date Int tinyint

Primary key Null Null Null

Not null

Foreign key

Receipt_ReturnDrug receipt_returnID amount dates ReceiptID Supplier supplierID SupplierName supplierAddress branchID

Number Number number number number number tex null

Tinyint int date tinyint tinyint Nvarchar(50) Nvarchar(75) tonyint

Primary key null Null null Primary key Null null null

Not null

Foreign key Not null

Foreign key 20

Data Analyzing and Designing

Supplier ContNo

supplierID supplierConNo

Number Numer

Tinyint Nvarchar(30)

Primary key Null

Not null

supplier_return

supplier_returnID invoiceID supplierID drugID quantity

number number number number number

tinyint tinyint tinyint tinyint int

Primary Key null null null null

Not null Foreign Key Foreign Key Foreign key

Table Name Dr_su1

Columns Name drugID supplierID

Columns Type number Number

Data Type tinyint tinyint

Column Status Primary key Primary key

Others

Not null

supplierDrug

supplierID drugID

number number

tinyint tinyint

Primary key null

Not null Foreig n Key

Invoice_drug

invoiceID quantity unitPrice discount

Number Number number number

tinyint int int float

Primary key Null Null null

Not null

Patient_Prescription

PatientID

number

tinyint

Primary

Not

21

Data Analyzing and Designing key PrescriptionID number tinyInt null null

Prescription_drug

prescriptionID NameOfTheDrug

number text number number number text

tinyint Nvarchar(150 ) tinyint tinyint Tinyint Nvarchar(50)

Primary key Primary Key Primary Key Primary Key Primary key null

Not null Not null Not null Not null Not null

prID_drID

prescriptionID drugID

Supplier_branch

supplierID supplierBranch

drugSupplier

drugID NameOfTheSuppl ier

number text

tinyint Nvarchar(150 )

Primary Key null

Not null

Supplier_returnDrug

Supplier _returnID drugID quantity amount

number number number number

tinyint tinyint int int

Primary Key Null Null null

Not null

branchContNo

branchID ContectNO nameOfTheDrug

number number number

tinyint Nvarchar(50) Nvarchar(100 )

Primary Key Null null

Not null

1.4
22

Data Analyzing and Designing

1.5
23

Data Analyzing and Designing

First normal form


There are two requirements for a table to be in first normal form: The table must have no duplicate records. This criteria is automatically met if you define a primary key for the table. The table must have no multi-valued attributes. This ones a little more complicated. Basically, it says that you cant combine multiple values that are valid for a column in a single column.

Second and third normal forms


The second normal form (2NF) introduces one additional requirement:all attributes that are not part of a candidate key must be functionally depen- dent upon the entire primary key. The third normal form (3NF) also requires that all attributes that are not part of a candidate key must be no transitively dependent upon each candidate key in the table. This means that the attributes may not be dependent only upon the primary key, because they are dependent upon another attribute that is dependent upon the primary key.

1.5
24

Data Analyzing and Designing

0NF

1NF

25

Data Analyzing and Designing

2NF and 3NF


26

Data Analyzing and Designing

Final Tables
27

Data Analyzing and Designing

Task-02
28

Data Analyzing and Designing

2.1
A database is a collection of data, which is organized into files called tables. These tables provide a systematic way of accessing, managing, and updating data. A relational database is one that contains multiple tables of data that relate to each other through special key fields. Relational databases are far more flexible (though harder to design and maintain) than what are known as flat file databases, which contain a single table of data. To KANDY PHARMACY scenario I selected this relational database. To understand the advantages of a relational database, imagine the needs of two small companies that take customer orders for their products. Company A uses a flat file database with a single table named orders to record orders they receive, while Company B uses a relational database with two tables: orders and customers. When a customer places an order with Company A, a new record (or row) in the table orders is created. Because Company A has only one table of data, all the information pertaining to that order must be put into a single record. This means that the customer's general information, such as name and address, is stored in the same record as the order information, such as product description, quantity, and price. If customers place more than one order, their general information will need to be re-entered and thus duplicated for each order they place. Whenever there is duplicate data, as in the case above, many inconsistencies may arise when users try to query the database. Additionally, a customer's change of address would require the database manager to find all records in orders that the customer placed, and change the address data for each one. Company B is much better off with its relational database. Each of its customers has one and only one record of general information stored in the table customers. Each customer's record is identified by a unique customer code which will serve as the relational key. When a customer orders from Company B, the record in orders need contain only a reference to the customer's code, because all of the customer's general information is already stored in customers. This approach to entering data solves the problems of duplicate data and making changes to customer information. The database manager need change only one record in customers if someone changes addresses. Relational database have main and big advantage which I mention above thats why I selected relational database model to create database for KANDY PHARMACY.

See implemented Database on CD KANDY PHARMACY

2.2
29

Data Analyzing and Designing

30

Data Analyzing and Designing

2.3
31

Data Analyzing and Designing The two types of constraints that primarily serve to enforce business logic in databases are the following: DEFAULT constraints supply values to fill fields when the user doesnt provide a value. CHECK constraints limit the values that users may insert into a particular database field. The three rules designed to support database relationships and enforce uniqueness are as follows: PRIMARY KEY constraints ensure that specified column always contain a unique value so that the column may serve as a tables primary key. UNQIUE constraints provide functionality similar to primary key constraints, but do not specify that the column(s) subject to the constraints are a tables primary key. FOREIGN KEY constraints link two tables in a database by requiring that the data in the column(s) governed by the constraint contain values stored in the primary key column(s) of the linked table.

CONSTRAINTS AND DIGGERS


Default create table patient ( patientID nvarchar(50) null patientName nvarchar(50) null branch nvarchar (50) null DEFAULT NeePharma ) Check Create table drug ( drugID int NOT NULL CHECK (drugID > 100), drugName varchar(50) NOT NULL, drugquantity int, drugUnitPrice float, drugGentric varchar(100) ) Primary Key CREATE TABLE branch ( branchId int NOT NULL PRIMARY KEY , brName varchar(255) NOT NULL, Address varchar(255),) Foreign key CREATE TABLE Orders( O_Id int NOT NULL PEIMARY KEY, OrderNo int NOT NULL, P_Id int FOREIGN key, OrderDate date ) Unique CREATE TABLE pharmacist ( P_Id int NOT NULL UNIQUE, LastName varchar(255) NOT NULL, FirstName varchar(255), Address varchar(255), branch varchar(255) ) I have used like which I explain above when I implement database for KANDY PHARMACY.

Task -03
32

Data Analyzing and Designing

3.1
BRANCH insert into branch(branchID,branchName,branchAddress) VALUES (8,'distarte','mahyava') update branch set branchName = 'qwa' where branchName = 'expo' delete from branch where branchName = 'gra'

3.2
1) select prescription.prescriptionID,prescription.nameOfthePatient,prescription.nameOfthephysician,pr escription.nameOfphrmacist,prescription.patientID, receipt.receiptID,receipt.amount,receipt.blance,receipt.branchID,receipt.patientID,receipt.phar macistID,receipt_drug.unitPrice,receipt_drug.quantity, (receipt_drug.unitPrice*receipt_drug.quantity) as ccc from prescription inner join receipt on receipt.prescriptionID= prescription.prescriptionID inner join receipt_drug on receipt.receiptID = receipt_drug.drugID 2) select drugID ,drugName from drug where drugQuantity <100 3) select SUM (drugQuantity * drugUnitprice) from drug 4) select patient.patientID from patient inner join receipt on patient.patientID = receipt.patientID group by patient.patientID having count (* )> 10

3.3
33

Data Analyzing and Designing

create trigger updateinvoice on receipt_drug for insert as declare @drugID as int = (select drugID from inserted) declare @quantity as int =(select quantity from inserted) declare @remainQuantity as int=(select drugQuantity from drug where drugID = @drugID) declare @totalRemainQuantity as int =@remainQuantity-@quantity update drug set drugQuantity = @totalRemainQuantity where drugID=@drugID

3.4
create trigger updatesupplier_return on supplier_return for insert as declare @drugID as int = (select drugID from inserted) declare @quantity as int =(select quantity from inserted) declare @stock as int=(select noOfDrug from stock where drugID = @drugID) declare @remainDrug as int =@stock-@quantity update stock set drugQuantity = @remainDrug where drugID=@drugID

3.5
1) create view supselect as select count(*)as counts,dbo.supplier.supplierID from dbo.SupplierDrug inner join dbo.supplier on dbo.SupplierDrug.supplierid=dbo.supplier.supplierID group by dbo.supplier.supplierID having count(*)>10 2) select sum ( drug.drugUnitPrice * drugQuantity) from drug inner join SupplierDrug on drug.drugID = supplierDrug.drugID

3.6
34

Data Analyzing and Designing 1) use KANDY PHARMACY create table supplier ( supplierID tinyint not null primary key, supplierName nvarchar(50)null, supplierAddress nvarchar (75)null ) 2) use KANDY PHARMACY create table drug ( drugID tinyint not null primary key, drugName nvarchar(50)null, drugQuantity int null, drugUnitPrice tinyint null, drugDiscount float null, drugGentric nvarchar(100)null )

Task-04
35

Data Analyzing and Designing

4.1
An index essentially behaves like an index in the back of a book or the table of contents at the front of a book. When searching for details on a specific topic, it is much easier to find the term in the index or table of contents first, and then use a page reference number to find the information within the pages of the text. Reading the entire book every time you want to find a definition for a single term would be far too time-consuming to be useful, probably making the book completely useless as a reference. Most technical books are used as reference guides in one form or another. An index is usually a copy of a very small section of table, such as a single field, and a short length field. The act of creating an index physically copies one or more fields to be indexed into a separate area of disk other than that of the table. In some databases, indexes can be stored in a file completely separated from that of the table. Different databases are structured differently on a physical level. The important factor is the underlying physical separation. Indexes helps SQL server get to the data faster. SQL server store data on pages. Page size is fixed at 8kb per page. There are several types of pages like data pages.if you have table that have 1000B row size ,you can store 8 rows per page .

How to create indexes?


Right click in any entity of database Manage indexes and keys

And choose design Design

Click Mange Indexes and Keys

36

Data Analyzing and Designing

Primary key

Place where we want to select primary key After you get this window you can look the primary key of the selected entity. If it is not you can select the primary key from (General)

Add

Close

37

Data Analyzing and Designing

4.2

Creating a maintenance plan


Click Management of any of database

Right click on the Maintenance plans

Choice Maintenance plan wizard

38

Data Analyzing and Designing

SQL server maintenance plan

wizard

Click Next

You will get the Select Plan Properties

39

Data Analyzing and Designing

Here we want to give a Name and if there any need to change you can change it, after this click Next

Select maintenance task

40

Data Analyzing and Designing

Here we want to select Back up database (full) to get whole back up of our database and click Next.

You will get Select maintenancetask order and just click next.

41

Data Analyzing and Designing

Define back up database (full) task

42

Data Analyzing and Designing

After finishing this step click Next

You will get Select Report Option Here dont do anything just click Next

43

Data Analyzing and Designing

44

Data Analyzing and Designing

If you get this dialog box it mean you finish you are back up successfully. Just click Finish

4.3
A data warehouse is a type of computer database that is responsible for collecting and storing the information of a particular organization. The goal of using a data warehouse is to have an efficient way of managing information and analyzing data.

45

Data Analyzing and Designing Over the last 20 years, $1 trillion has been invested in new computer systems to gain competitive advantage. The vast majority of these systems have automated business processes, to make them faster, cheaper, and more responsive to the customer. Electronic point of sales (EPOS) at supermarkets, itemized billing at telecommunication companies (telcos), and mass market mailing at catalog companies are some examples of such Operational Systems. These systems computerized the day-to-day operations of business organizations. Some characteristics of the operational systems are as follows:

Most organizations have a number of individual operational systems (databases, applications) On-Line Transaction Processing (OLTP) systems capture the business transactions that occur. An Operational System is a system that is used daily (perhaps constantly) to perform routine operations - part of the normal business processes. Examples: Order Entry, Purchasing, Stock/Bond trading, bank operations. Users make short term, localized business decisions based on operational data. e.g., "Can I fill this order based on the current units in inventory?"

Presently almost all businesses have operational systems and these systems are not giving them any competitive advantage. These systems have gathered a vast amount of data over the years. The companies are now realizing the importance of this hidden treasure of information. Efforts are now on to tap into this information that will improve the quality of their decision-making. A data warehouse is nothing but a repository of data collected from the various operational systems of an organization. This data is then comprehensively analyzed to gain competitive advantage. The analysis is basically used in decision making at the top level. From being just a passing fad, Data Warehousing technology has grown much in scale and reputation in the past few years, as evidenced by the increasing number of products, vendors, organizations, and yes books, even books, devoted to the subject. Enterprises that have successfully implemented data warehouses find it strategic and often wonder how they ever managed to survive without it in the past. As early as 1995, a Gartner Group survey of Fortune 500 IT managers found that 90% of all organizations had planned to implement Data Warehouses by 1998. Be for one year Srilanka had big healthy problem that was swine flu at that particular time in all branch of KANDY PHARMACY anti swine flu tablets sales was very high. When it controlled tablets sales was decrease by half percentage. This is the good example of data warehousing in KANDY PHARMACY. Usually in rainy period Srilanka have dengue fever at those time also we can see in the all of KANDY PHARMACY branches , anti-dengue drugs are selling very fast but other normal dates this sale not be there

4.4.

46

Data Analyzing and Designing

Go to Visual Studio 2008

Select View

Select Sever Explorer

In the

Sever Explorer Connection

There is Data Connection ,Right click on it

Select Add

47

Data Analyzing and Designing

48

Data Analyzing and Designing

Click OK

Click OK

Now you can see KANDY PHARMACY database and its tables in visual studio 2008

49

Data Analyzing and Designing

Conclusion
Completion of this project I gained a vast amount of knowledge by doing the assignment of DAD myself. So I feel this subject to be very interesting and knowledge providing and it was a big task to do in my career and now I have succeeded in producing my assignment after a hard work. Throughout this assignment I have improved a lot in self-studying, justification, Analysis for my upcoming studies too. So this is a good experience in my studies and life to take decision in a practical environment. Im quite sure this knowledge will be helpful in my further success in the future.

References

Books Microsoft.SQL.Server.2008.For.Dummies Absolute Beginner's Guide to databases. Database Beginner Guide. Beginning Database Design. Video tutorials Lynda.coms MS SQL video tutorials Websites http://dev-odbc.groupbc.com/bchelp/sec-8-0.html http://kb.iu.edu/data/ahrp.html http://en.wikibooks.org/wiki/The_Computer_Revolution/Databases/Database_Models http://www.jwrider.com/lab/datamodels.htm 50

Data Analyzing and Designing http://www.tonymarston.net/php-mysql/database-design.html#hierarchical.db http://en.wikipedia.org/wiki/Database_model http://www.exforsys.com/tutorials/data-warehousing/data-warehousing-introduction.html

51

S-ar putea să vă placă și