1 / 22

International Issues in DIS

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

suki
Download Presentation

International Issues in DIS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. International Issues in DIS Week 13 - Lecture 1

  2. 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

  3. We will consider the issues not the solutions • As the solutions often depend on the • Operating system • DBMS • Application

  4. 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

  5. Issues • Currency • Calendar • Character sets • Language • Legal & Accounting • Privacy legislation • Cultural & commercial

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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.

  17. 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

  18. 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

  19. 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

  20. 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

  21. 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

  22. 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

More Related