•
•
•
•
What is DaniWeb IT Discussion Community?
You're currently browsing the Database Design section within the Web Development category of DaniWeb, a massive community of 429,752 software developers, web developers, Internet marketers, and tech gurus who are all enthusiastic about making contacts, networking, and learning from each other. In fact, there are 3,992 IT professionals currently interacting right now! Registration is free, only takes a minute and lets you enjoy all of the interactive features of the site.
Please support our Database Design advertiser: Programming Forums
Views: 867 | Replies: 7
![]() |
•
•
Join Date: Jun 2008
Posts: 5
Reputation:
Rep Power: 0
Solved Threads: 0
Hi,
I am a bit confused and wish to share this with you for help. We are designing a billing application to bill telephone calls. It currently handles a single rate plan. So what it does is that it looks up the RATES table and matches the called number area code with the RATES.ACCESS_Code field to find the tariff for that area and multiplies that by the number of minutes. Here is the current schema.
CALLS
• ID (pkid)
• Called Number
• Duration
RATES
• Destination Name
• Access_Code (pkid)
• Tariff
Now the problem is that we need to process calls based on RATES per OPERATOR. Each operator is a telephony carrier with similar RATES. However, each call will be prefixed with a number to indicate which operator carried that call. Accordingly, the database should relate that prefix with the proper operator and then looks up the RATES that are related to that operator.
In conclusion we will have a replica of the RATES table for multiple operators. An operator is only supposed to have two fields I guess (name and ID).
So now we need to re-engineer the schema to adapt to this situation.
Eg. 95004433313445 (Will be identified as BT operator)
93004422376234 (Will be identified as AT&T operator)
Can anyone help please?
Thanks
I am a bit confused and wish to share this with you for help. We are designing a billing application to bill telephone calls. It currently handles a single rate plan. So what it does is that it looks up the RATES table and matches the called number area code with the RATES.ACCESS_Code field to find the tariff for that area and multiplies that by the number of minutes. Here is the current schema.
CALLS
• ID (pkid)
• Called Number
• Duration
RATES
• Destination Name
• Access_Code (pkid)
• Tariff
Now the problem is that we need to process calls based on RATES per OPERATOR. Each operator is a telephony carrier with similar RATES. However, each call will be prefixed with a number to indicate which operator carried that call. Accordingly, the database should relate that prefix with the proper operator and then looks up the RATES that are related to that operator.
In conclusion we will have a replica of the RATES table for multiple operators. An operator is only supposed to have two fields I guess (name and ID).
So now we need to re-engineer the schema to adapt to this situation.
Eg. 95004433313445 (Will be identified as BT operator)
93004422376234 (Will be identified as AT&T operator)
Can anyone help please?
Thanks
•
•
Join Date: May 2006
Location: ★ ijug.net ★
Posts: 943
Reputation:
Rep Power: 5
Solved Threads: 67
Add operator id in the table rate may be.
•
•
Join Date: Apr 2008
Posts: 295
Reputation:
Rep Power: 1
Solved Threads: 41
Hi wzb,
Do not create separate RATES tables for various operators. All rates with identifying operator information should be in one table. If not, you would run into difficulties when creating SQL select statements.
krs,
tesu
•
•
•
•
. . .
CALLS
• ID (pkid)
• Called Number
• Duration
RATES
• Destination Name
• Access_Code (pkid)
• Tariff
. . .
In conclusion we will have a replica of the RATES table for multiple operators. An operator is only supposed to have two fields I guess (name and ID).
So now we need to re-engineer the schema to adapt to this situation.
Eg. 95004433313445 (Will be identified as BT operator)
93004422376234 (Will be identified as AT&T operator)
. . .
You can create new table Operators OPERATORS • operatorID (pk) • name Then add operatorID to RATES newRATES • Destination Name • Access_Code (pkid) • operatorID (pk ??) • Tariff I hope you can select the right operator for a given "Called Number".
Do not create separate RATES tables for various operators. All rates with identifying operator information should be in one table. If not, you would run into difficulties when creating SQL select statements.
krs,
tesu
•
•
Join Date: Jun 2008
Posts: 5
Reputation:
Rep Power: 0
Solved Threads: 0
Hi tesu,
Thanks for your response. I have thought of this already but then it will create a problem. In the NewRates table, the field (Access_Code) which is a (pkid) is supposed to be unique. However, I need to enter the tariff for the same access code on per operator basis. Meaning I will need to have two (001) - as USA for both operator1 and operator2. Did you get what I mean?!
I liked this schema because it is making my life easy when querying the databse.
Let me know your thoughts.
Thanks
Thanks for your response. I have thought of this already but then it will create a problem. In the NewRates table, the field (Access_Code) which is a (pkid) is supposed to be unique. However, I need to enter the tariff for the same access code on per operator basis. Meaning I will need to have two (001) - as USA for both operator1 and operator2. Did you get what I mean?!
I liked this schema because it is making my life easy when querying the databse.
Let me know your thoughts.
Thanks
•
•
Join Date: Apr 2008
Posts: 295
Reputation:
Rep Power: 1
Solved Threads: 41
Hi wzb
I also assumed this. It has been the reason why I wrote operatorID (pk ??) in newRates. So opeatorID must become part of pk. Hope this will work.
krs,
tesu
•
•
•
•
Hi tesu,
... In the NewRates table, the field (Access_Code) which is a (pkid) is supposed to be unique. However, I need to enter the tariff for the same access code on per operator basis. Meaning I will need to have two (001) - as USA for both operator1 and operator2...
I also assumed this. It has been the reason why I wrote operatorID (pk ??) in newRates. So opeatorID must become part of pk. Hope this will work.
krs,
tesu
•
•
Join Date: Apr 2008
Posts: 295
Reputation:
Rep Power: 1
Solved Threads: 41
hi wzb
Primary key of newRates should consist of Access_Code and operatorID to allow that same access code can be assigned to various operators. Like in:
Thus far, I have a problem with your data model: If a call is made, the information is recorded in the CALLS table. CALLS table has called number and duration to compute the total amount. To do this you need the tariff of the operator, e.g. from AT@T. what operated that specific call. Is this necessary information stored in CALLS, maybe together with called number?
krs,
tesu
Primary key of newRates should consist of Access_Code and operatorID to allow that same access code can be assigned to various operators. Like in:
sql Syntax (Toggle Plain Text)
CREATE TABLE newRates(DestinationName varchar(10) NOT NULL, Access_Code varchar(15) NOT NULL, operatorID varchar(15) NOT NULL, Tariff decimal(10.4), PRIMARY KEY (Access_code, operatorID), FOREIGN KEY (operatorID) REFERENCES operators);
Thus far, I have a problem with your data model: If a call is made, the information is recorded in the CALLS table. CALLS table has called number and duration to compute the total amount. To do this you need the tariff of the operator, e.g. from AT@T. what operated that specific call. Is this necessary information stored in CALLS, maybe together with called number?
krs,
tesu
•
•
Join Date: Jun 2008
Posts: 5
Reputation:
Rep Power: 0
Solved Threads: 0
Hi tesuji,
Yes you are right, I need to identify the operator before the actual call rating. I intend to do that by creating a query to match the prefix that the user dials before the actual number. I also intend to have this match the OperatorID. From a configuration perspective, I will give the user the option to configure the application with all the possible operators that they use it to operate calls along with their prefix which I will use as the operatorID. What do you think of this model? Is there a better alternative?
thanks
wzb
Yes you are right, I need to identify the operator before the actual call rating. I intend to do that by creating a query to match the prefix that the user dials before the actual number. I also intend to have this match the OperatorID. From a configuration perspective, I will give the user the option to configure the application with all the possible operators that they use it to operate calls along with their prefix which I will use as the operatorID. What do you think of this model? Is there a better alternative?
thanks
wzb
![]() |
•
•
•
•
•
•
•
•
DaniWeb Database Design Marketplace
•
•
•
•
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
•
•
•
•
age amd avatar backup blue gene breach business chips daniweb data data protection database development dos economy energy enterprise europe government hacker hardware hp ibm ibm. news intel ibm it linux medicine memory microsoft news open source openoffice pc ps3 recession red hat russia security server sql sun supercomputer supercomputing survey technology trends ubuntu working x86
- memory management in wndows 2000 (Windows NT / 2000 / XP / 2003)
- Help for learnign JSP (JSP)
- Database Design (Database Design)
- Sr. Java Developers Needed (Software Development Job Offers)
- Java Tutorials (Java)
- Oracle Help Needed (Oracle)
- Please Review My Database Design (Database Design)
Other Threads in the Database Design Forum
- Previous Thread: database data entry problem
- Next Thread: Database Schema for a boat


Linear Mode