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, –ITL9,999,999,999,999,999 –IDR99,999,999,999,999, –TRL999,999,999,999,999, 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 –EuropeanYYYYMMDD 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 1 st 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 for a good paper on character sets. Another useful paper on character sets is for an overview of internationalising a systemhttp://

Encoding schemes We now have Unicode – ISO/IEC 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