Reference no: EM133255570

DISTRIBUTORS DATABASES 

Sources: Mallach, E., & Taylor & Francis. (2020). Information systems: What every business student needs to know (Second ed., Chapman & Hall/CRC textbooks in computing). 

Visal Phan, KCD's database administrator, was returning from a lunchtime walk just as Isabella and Jake arrived at the building's front door. They were a few minutes early, but he ushered them into the now-familiar IS department conference room. He opened the conversation with "What did Lakshmi tell you about our databases last week?" "She said that you use Oracle's database manager on your central system and on the servers in the distribution centers," Isabella answered. "Nothing more than that." "Actually," Jake interjected, "she did say one other thing. She said Oracle's version numbers just jumped from 12c to 18c, but she didn't know why. We thought you might." "It's not a secret," Visal replied, "though I can understand that she never had a reason to ask. Up through 12, they were numbered in sequence. Then Oracle decided to number each version for the year it came out. Version 18 came out in 2018. 18c is its third update. It's that simple. "Anyhow," he continued, "she's right. Oracle is pretty much the only database software we use. A few people build small personal databases using Access or FileMaker Pro, but I don't get involved with those unless someone asks me for advice. 

"As far as the Oracle database is concerned, what we have is fairly typical of the distribution business. We work with candy, but our database could be about almost anything. From a user point of view there are four kinds of data in the system, plus others behind the scenes that our users don't care about. We have data about customers, parts of KCD, suppliers, and transactions such as sales. Some kinds of data, like products, overlap these categories. That's what makes it a database and not just a collection of files. 

"The problem is databases are like onions. Peel one layer away, and you find another. Then you peel that one away and see the next one. It keeps going for way more layers than you'd think. For instance, take a customer file. Our customers are businesses, but there's a person at each one who's authorized to place orders. We can't put that person in the customer record, because they can change over time and we can't lose information about who placed previous orders. So, purchasing agents are another entity. Then we have to have the dates that a given purchasing agent started and ended. We can't put those in the purchasing agent record, because sometimes someone who was the agent in the past comes back again later, so we have another entity for the period that a person is a purchasing agent. And some customers authorize more than one person to place orders, so the database structure needs to allow for that." 

"That's a lot more complicated than what we did in our database course," said Isabella. Jake nodded agreement and added, "We did a sales database exercise, but a customer was just a customer. Customers had customer numbers as primary keys, names, addresses, that sort of thing, but it didn't go past that." "Right," Visal agreed, "but the concepts are the same. It's like reading. I learned to read English, after my family came here from Cambodia, on really simple stuff. Once I knew how to read, I could pick up a newspaper without having to learn a new way of reading. It took longer to figure out sentences, and I had to learn new slang to understand the sports pages, but reading was reading. The things I had learned were still useful. Your database course is like that. You have the concepts. You just have to apply them to more complicated situations." 

"That's what our professor said," Jake agreed, "but it means more when you hear it from someone who works with real databases for a living." "Your professor was right, at least this time," Visal laughed. "Anyhow, all the information we keep for our customers works the other way too, for our suppliers. We have data for each order we place with them, and for each item in each order because each item is a different product. When we record that an order arrives, we have to allow for split shipments-not just of the order, but of each item. We have to be able to record partial and full payments, credits that aren't payments, partial and full returns, and more. And then we have to transfer what we get into inventory, and keep track of that. We're getting ready to use tiny RFID transponders for inventory tracking. Never a dull moment!" 

Answer all the questions below: 

1. Describe the difference between Oracle database and SQL database. 

2. The best way to organise a database with 100 records won't handle 100 million records. As a database grows, it must be reorganised. If it isn't, response time will degrade and impact on performance, which requires restructuring. This restructuring need not be done often or during business hours, but when it is done, the database is unavailable for a few hours. Suggest two ways to minimise the business impact of this outage. 

3. Define data and information, giving an example of the difference between them?