220 likes | 306 Views
International Issues in DIS. Week 13 - Lecture 1. DIS cross country boundaries. Either with one set of application and database servers for a group of countries Or, with separate application and database servers in each country. Often not cost efficient
E N D
International Issues in DIS Week 13 - Lecture 1
DIS cross country boundaries • Either with one set of application and database servers for a group of countries • Or, with separate application and database servers in each country. • Often not cost efficient • Transactions and queries cross country boundaries • Applications should be designed for implementation in different countries
We will consider the issues not the solutions • As the solutions often depend on the • Operating system • DBMS • Application
Textbooks and software originates in the USA • The US market is big, and international aspect have often been overlooked • Textbooks don’t cover these issues • But major software houses are much better now than five years ago
Issues • Currency • Calendar • Character sets • Language • Legal & Accounting • Privacy legislation • Cultural & commercial
Currency Software often handles this reasonably well • Local currency symbols are ambiguous • $ for US, Australian and New Zealand dollar • Newspapers often use $US, $A, $NZ • ISO standard is USD, AUD, NZD
Field sizes in many packages are a trap • Often defined for USD but Indonesian Rupiah, Italian Lira and Turkish lira need four more digits, plus the currency symbol • USD999,999,999,999.00 • ITL9,999,999,999,999,999 • IDR99,999,999,999,999,999.00 • TRL999,999,999,999,999,999.00 • Database, screen & reports have to allow for these
Currency conversion • Transactions normally recorded in the currency in which it is negotiated • Usually this is the currency of the country making the sale, but not always • Countries with volatile currencies often use a major currency for big contracts
Accountants have conversion rules • Reporting usually requires reporting in the currency of the country concerned or the organisations global currency – usually the currency of the dominant country • But it can’t be done at reporting time and should be stored on the transaction • Often each transaction is converted at the rate on the date of the transaction, but some organisations use a set rate for the month or quarter • Assets and liabilities have to be converted annually • Debts raised in one currency and settled in another result in exchange differences
Calendar • The de facto international standard is the Gregorian calendar - the Julian calendar with minor modifications by Pope Gregory in 1582 • There are others - Chinese, Japanese, Thai, Persian and Arabic calendars • Oracle’s DBMS will convert if asked
Other calendar problems are: • The different numeric date formats • Australian DDMMYYYY • The US MMDDYYYY • European YYYYMMDD • Probably the DD MMM YYYY is the most unambiguous • But then language affects the month abbreviations
Week numbering is sometimes used in systems • The English tradition is that the week starts on Sunday • But the ISO standard has the week starting on Monday • Depending on which day the 1st Jan falls on, this can result in different week numbers
Encoding schemes • Computers were initially designed to have one byte with 8 bits and 256 combinations represent the different characters • The 7 bit ASCII and IBM’s 8 bit EBCDIC were the two most common standards • But most countries don’t use the standard Latin character set • Oracle lists some 178 character sets, see http://otn.oracle.com/tech/globalization/pdf/Unicode.PDF for a good paper on character sets. • Another useful paper on character sets is http://www.unicode.org/standard/principles.html • http://www.microsoft.com/globaldev/getwr/steps/wrguide.mspx for an overview of internationalising a system
Encoding schemes • We now have Unicode – ISO/IEC 10646 • Originally was to be 16 bit, but now • Either 8 bit, 16 or 32 bits • All include the 256 character Latin 1 character set • Windows, XML and much other system software use/support Unicode • Each character is unique and given a plain text name, leaving the font to assign a glyph
Sorting is another issue • Binary sorts often do not work with other than the 26 character Latin alphabet • An ORDER BY would produce ABC, ABZ, BCD, BC, as has a higher numeric value than B • Linguistic sorts are therefore required, but these may not work with multi-byte character sets??? • A Linguistic sort will handle special cases such as the Spanish “ch” which is treated as one character and should sort between c and d
Language • Ideally, if a database is to be updated by people from a number of countries, each should be able to do so in their own language.
But there are problems • Imagine if the staff in multiple countries recorded their names in their own language (and character set) – and we asked for a list of all staff – could we read it? • But the same system would need to print employment contracts in the local language • One approach is to record some details twice – in the local language and in a common language
More on language • Messages can be generated by the client O/S, the Server O/S, DBMS and the Application. Many do allow language selection. In house systems have to provide their own facilities • Screen prompts, report headings and other text also need to adapt • Conversion at the Web server or in the Browser is an emerging approach • Has to adapt to the user • O/S commands and DBMS keywords often have to be in English. DBMS tables names etc have to be in single byte characters
Legal and accounting differences • To an IT person they seem obtuse and trivial • But they are important and the organisation can be subject to heavy penalty • The systems architect needs to work with legal and accounting people, and get sign off on the solution • Make sure you understand the issue as sometimes a simple IT solution can save accounting a lot of work
Legal requirements • Taxes. Many countries have GST or VAT but they are all different • Layout of tax invoices • Calculation of taxable amounts • Who or what is taxable or exempt • Government reporting is different • Italy requires a daily list of all transactions • Eastern European countries still require the old communist reporting – strict cash format, with huge fines for minor infringements
EEC Privacy regulation • Each country implements it differently • Restricts personal information from going to countries without similar controls • Requires secure data transmission and secure processing • Limits type of data that can be collected • Prevents data from being used for other purposes • Other countries have privacy legislation but often it has a different emphasis i.e. in the US data collected about people belongs to the collector
Cultural & Commercial differences • Some examples are: • How correspondence is addressed, the format of the name, the layout of the address, the size of the envelope • Method for settlement of a debt • US uses direct credit • Australia uses credit cards, cheques and increasingly electronic means like BPay • Europe has the Giro