Conheça os recursos internacionais do Microsoft SQL Server 2005
Aplica-se ao:
| • | Microsoft SQL Server 2005 |
| • | Unicode |
Resumo
Este white paper apresenta os recursos internacionais do Microsoft SQL Server 2005 a desenvolvedores do Microsoft SQL Server. Os tópicos abordados incluem uma explicação sobre o Unicode, suporte adicional para caracteres suplementares no SQL Server 2005, alterações em agrupamentos em diferentes versões do SQL Server, alterações em tipos de dados, desempenho, atualizações em provedores de dados e os novos recursos de suporte internacional do SQL Server 2005 Analysis Services e do SQL Server 2005 Integration Services. (75 páginas impressas)
Clique para obter a versão deste documento para Word.
Nesta página
Introdução
O Microsoft SQL Server 2005 se baseia no suporte a Unicode e a XML introduzido no SQL Server 2000 e acrescenta um novo conjunto de ferramentas de consulta e desenvolvimento com o SQL Server Management Studio e o Business Intelligence Development Studio. Recursos multilíngües robustos tornam o SQL Server 2005 uma plataforma de aplicativos e produtos de banco de dados atraente para o suporte de ambientes e operações internacionais.
Este white paper oferece uma visão geral desses recursos em um contexto global. Ele lista recursos relacionados a requisitos internacionais e multilíngües e explica como as decisões de design podem afetar muitos aspectos de um projeto.
Observação Este artigo usa as seguintes fontes para fornecer exemplos de alguns caracteres internacionais: Arial Unicode MS, Latha, Mangal, PmingLiu, Gulim, SimSun e MS-Mincho. O fato de não ter essas fontes instaladas não afetará muito a usabilidade deste artigo.
Suporte a Unicode no SQL Server 2005
O suporte a Unicode é a base para o suporte multilíngüe no SQL Server 2005.
O Unicode é um padrão criado pelo Consórcio Unicode, uma organização que promove o uso de um único conjunto de caracteres para todos os idiomas. O SQL Server 2005 dá suporte ao Padrão Unicode, versão 3.2. A versão 3.01 é idêntica ao ISO-10646, um padrão internacional que corresponde a todos os pontos de código no Unicode.
O Unicode fornece um ponto de código exclusivo para cada caractere, seja qual for a plataforma, o programa ou o idioma. Um programa com suporte a Unicode pode manipular dados em qualquer idioma. Como ele foi projetado para cobrir todos os caracteres de todos os idiomas do mundo, não há necessidade de diferentes páginas de código para manipular diferentes conjuntos de caracteres.
Como todos os sistemas Unicode usam os mesmos padrões de bits para representar todos os caracteres, não há problema nenhum em os caracteres serem convertidos incorretamente durante a movimentação de um sistema para outro.
A maneira mais fácil de gerenciar dados de caracteres em bancos de dados internacionais é usar os tipos de dados Unicode nchar, nvarchar e nvarchar(max), em vez de seus equivalentes não-Unicode: char, varchar e text. Dessa forma, os clientes verão os mesmos caracteres nos dados que todos os outros clientes. Se todos os aplicativos que funcionam com bancos de dados internacionais também usarem variáveis Unicode em vez de não-Unicode, as conversões de caracteres não precisarão ser executadas no sistema.
Observação O tipo de dados ntext será removido em uma futura versão do Microsoft SQL Server.
Os pontos de código Unicode e os caracteres que eles representam são separados do glyph, que é usado para processamento visual. Um glifo é definido pelo padrão ISO (ISO/IEC 9541-1) como "um símbolo gráfico abstrato reconhecível que independe de um design específico". Por isso, não necessariamente um caractere é representado sempre pelo mesmo glifo ou até mesmo por um glifo exclusivo. A face de tipos que você escolher determinará qual glifo será usado para representar um ponto de código ou uma série de pontos de código em particular.
Para obter mais informações, consulte o site do Consórcio Unicode.
Codificações
O Unicode mapeia pontos de código para caracteres, mas não especifica realmente como os dados serão representados na memória, em um banco de dados ou em uma página da Web. É aí que a codificação de dados Unicode entra em ação. Existem muitas codificações diferentes para o Unicode. Na maior parte do tempo, você pode simplesmente escolher um tipo de dados Unicode e não se preocupar com esses detalhes. Entretanto, é importante compreender a codificação quando você está nas seguintes situações:
| • | Ao lidar com um aplicativo que pode codificar o Unicode de forma diferente |
| • | Ao enviar dados para outras plataformas (que não sejam Microsoft Windows) ou servidores Web |
| • | Ao importar dados de outras codificações ou exportá-los para elas |
O padrão Unicode define várias codificações do único conjunto de caracteres que ele possui: UTF-7, UTF-8, UTF-16 e UTF-32. Esta seção descreve estas codificações comuns:
| • | UCS-2 |
| • | UTF-16 |
| • | UTF-8 |
Geralmente, o SQL Server armazena o Unicode no esquema de codificação UCS-2. Entretanto, muitos clientes processam o Unicode em outro esquema de codificação, como o UTF-8. Esse cenário costuma ocorrer com freqüência em aplicativos baseados na Web. Em aplicativos Microsoft Visual Basic, as cadeias de caracteres são processadas no esquema de codificação UCS-2. Por isso, você não precisa especificar explicitamente as conversões do esquema de codificação entre aplicativos Visual Basic e uma instância do SQL Server.
O SQL Server 2005 codifica dados XML usando o Unicode (UTF-16). Os dados em uma coluna do tipo xml são armazenados em um formato interno como BLOBs (objetos binários grandes) para dar suporte a características do modelo XML, como estruturas recursivas e ordem de documentos. Por isso, os dados XML recuperados do servidor vêm em UTF-16. Se você quiser uma codificação diferente para recuperação de dados, o aplicativo deve executar a conversão necessária nos dados UTF-16 recuperados. Práticas recomendadas para XML nos Manuais Online do SQL Server 2005 apresenta um exemplo de como declarar explicitamente uma codificação de dados XML recuperados de uma coluna varchar(max).
A codificação UTF-16 é usada porque pode manipular caracteres de 2 ou 4 bytes, além de ser processada de acordo com um protocolo orientado a bytes. Essas qualidades tornam o UTF-16 bastante adequado para percorrer diferentes computadores que usam diferentes codificações e sistemas de ordenação de bytes. Como normalmente os dados XML são largamente compartilhados pelas redes, faz sentido manter o armazenamento UTF-16 padrão dos dados XML em seu banco de dados ao exportá-los para clientes.
UCS-2
O UCS-2 é um predecessor do UTF-16. A diferença entre eles é que o UCS-2 é uma codificação de comprimento fixo que representa todos os caracteres como um valor de 16 bits (2 bytes) e, por isso, não oferece suporte a caracteres suplementares. Embora mais limitado, ele é confundido freqüentemente com o UTF-16, que é usado para representar texto internamente nos sistemas operacionais Microsoft Windows (Windows NT, Windows 2000, Windows XP e Windows CE).
Observação Para obter informações atualizadas sobre o uso do Unicode no sistema operacional Windows, consulte Unicode na Biblioteca do Microsoft Developer Network (MSDN). É recomendável que um aplicativo Windows use o UTF-16 internamente e converta pela interface, como parte de uma "camada fina", somente se outro formato precisar ser usado.
As informações armazenadas em Unicode no Microsoft SQL Server 2000 e no Microsoft SQL Server 2005 usam a codificação UCS-2, que armazena todos os caracteres como dois bytes, seja qual for o caractere usado. Sendo assim, a letra latina "A" é tratada da mesma forma que a letra cirílica Sha ()), a letra hebraica Lamed (ì), a letra tâmil Rra (?) ou a letra hiragana E (‚¦). Cada uma tem um ponto de código exclusivo (para essas letras, os pontos de código são U+0041, U+0248, U+05DC, U+0BB1 e U+3048, respectivamente, onde cada número hexadecimal de quatro dígitos representa os dois bytes usados pelo UCS-2).
Como o UCS-2 permite a codificação de apenas 65.536 pontos de código diferentes, ele não manipula nativamente caracteres suplementares. Em vez disso, ele trata esses caracteres como um par de caracteres substitutos Unicode indefinidos que, quando emparelhados, definem um caractere suplementar. Entretanto, o SQL Server pode armazenar caracteres suplementares sem risco de perdas ou danos. Você pode estender os recursos do SQL Server para trabalhar com pares substitutos criando funções CLR personalizadas. Para obter mais informações sobre como trabalhar com pares substitutos e caracteres suplementares, consulte a seção "Caracteres suplementares e pares substitutos", mais adiante neste artigo.
Observação Os caracteres suplementares são definidos como um caractere codificado com Unicode que tem um ponto de código suplementar. Os pontos de código suplementares estão no intervalo entre U+10000 e U+10FFFF.
UTF-8
O UTF-8 é um esquema de codificação desenvolvido para tratar os dados Unicode de modo que eles não dependam da ordenação de bytes no computador. O UTF-8 é útil para trabalhar com ASCII e outros sistemas orientados a byte que requerem codificações de 8 bits, como servidores de email que precisam abranger uma série de computadores que usam diferentes codificações, ordens de byte e idiomas. Embora o SQL Server 2005 não armazene dados em formato UTF-8, ele dá suporte a UTF-8 para manipular dados XML. Para obter mais informações, consulte a seção Suporte a XML no SQL Server 2005 deste artigo.
Outros sistemas de banco de dados, como Oracle e Sybase SQL Server, oferecem suporte a Unicode usando o armazenamento UTF-8. Dependendo da implementação de um servidor, isso pode ser tecnicamente mais fácil para um mecanismo de banco de dados implementar, porque o código de gerenciamento de texto existente no servidor não requer grandes alterações para lidar com dados um byte de cada vez. Entretanto, no ambiente do Windows, o armazenamento UTF-8 possui diversas desvantagens:
| • | O COM (Component Object Model) oferece suporte somente a UTF-16/UCS-2 em suas APIs e interfaces. Por isso, se os dados estiverem armazenados em formato UTF-8, é necessária uma conversão constante. Esse problema ocorre somente quando o COM é usado. Normalmente, o mecanismo de banco de dados do SQL Server não chama interfaces COM. |
| • | Os kernels do Windows XP e do Windows Server 2003 são Unicode. O UTF-16 é a codificação padrão para Windows 2000, Windows XP e Windows Server 2003, mas eles reconhecem o UTF-8. Por isso, o uso de um formato de armazenamento UTF-8 no banco de dados requer muitas conversões adicionais. Normalmente, os recursos extras necessários para a conversão não afetam o mecanismo de banco de dados do SQL Server, mas pode vir a afetar muitas operações do lado do cliente. |
| • | O UTF-8 pode ser mais lento para muitas operações com cadeias de caracteres. A ordenação, a comparação e praticamente qualquer operação com cadeias de caracteres pode ser mais lenta porque os caracteres não têm uma largura fixa. |
| • | Geralmente, o UTF-8 precisa de mais do que 2 bytes, e o tamanho aumentado pode criar uma impressão digital maior no disco e na memória. |
Apesar dessas adversidades, visto que o XML se tornou um padrão importante para comunicação pela Internet, convém considerar a possibilidade de usar o UTF-8 como padrão.
Observação Versões mais antigas do Oracle e do Java também usam o UCS-2 e não reconhecem substitutos. A Oracle Corporation começou a oferecer suporte a Unicode como um conjunto de caracteres de banco de dados no Oracle 7. No momento, ela dá suporte a dois métodos para armazenamento de dados Unicode: (1) UTF-8 como a codificação para os tipos de dados de caracteres CHAR e VARCHAR2 e para todos os literais ou nomes SQL; (2) UTF-16 para armazenamento dos tipos de dados Unicode NCHAR, NVARCHAR e NCLOB. A Oracle permite o uso simultâneo dos dois métodos.
UTF-16
O UTF-16 é o padrão de codificação na Microsoft. No sistema operacional Windows, ele é uma extensão que foi desviada para manipular 1.048.576 caracteres adicionais. A necessidade de um intervalo substituto foi reconhecida mesmo antes que o Unicode 2.0 fosse lançado, quando ficou claro que o objetivo da Unicode de ter um único ponto de código para cada caractere em todos os idiomas não poderia ser alcançado usando somente 65.536 caracteres. Por exemplo, em alguns idiomas, como o chinês, essa quantidade de caracteres é o mínimo para codificar caracteres como ideogramas literários e históricos que, embora raramente usados, são importantes para editoras e o mundo acadêmico. A próxima seção fornece mais informações sobre o intervalo substituto.
Da mesma forma que o UCS-2, o UTF-16 usa uma ordem de byte little endian, como tudo no Windows. Ao contrário da big endian, a little endian significa que o byte de ordem inferior é armazenado no menor endereço na memória. A ordenação de bytes é importante no nível de sistema operacional. O SQL Server, junto com outros aplicativos que são executados na plataforma Windows, usa a ordem de byte little endian. Por isso, uma palavra hexadecimal como 0x1234 é armazenada na memória como 0x34 0x12. Em certos casos, talvez seja necessário reverter explicitamente a ordem de byte para ler corretamente a codificação de um caractere. O SQL Server Integration Services oferece funções para converter a ordem de byte do texto Unicode. Para obter mais informações, consulte a seção SQL Server 2005 Integration Services deste artigo.
Caracteres suplementares e pares substitutos
O Microsoft Windows normalmente usa o UTF-16 para representar dados de caracteres. O uso de 16 bits permite a representação de 65.536 caracteres exclusivos. Entretanto, isso ainda não é suficiente para abranger todos os símbolos usados nas línguas naturais. No UTF-16, determinados pontos de código usam outro ponto de código logo após os dois primeiros bytes para definir o caractere como parte do intervalo substituto.
No padrão Unicode, existem 16 planos de caracteres, com potencial para definir até 1.114.112 caracteres. O plano 0 – o BMP (Plano Multilingual Básico) – pode representar a maioria dos scripts escritos do mundo, caracteres usados na publicação, símbolos técnicos e matemáticos, formas geométricas, marcas de pontuação e todas as Zapf Dingbat de nível 100.
Fora do BMP, os caracteres na maioria dos planos ainda estão indefinidos, mas podem ser usados para representar caracteres suplementares. Esses caracteres são usados basicamente com documentos literários clássicos e históricos, para ajudar na codificação da rica herança literária dos idiomas chinês, coreano e japonês. Os caracteres suplementares também incluem runas e outras escritas históricas, símbolos musicais, etc.
No UTF-16, um par de pontos de código, chamado par substituto, é usado para representar caracteres fora do conjunto de caracteres principal (o BMP). A área substituta é um intervalo em Unicode de U+D800 a U+DFFF que contém 1.024 valores substitutos baixos e 1.024 valores substitutos altos. Um substituto alto (o intervalo de U+D800 a U+DBFF) e um substituto baixo (o intervalo de U+DC00 a U+DFFF) são combinados para dar acesso a mais de um milhão de caracteres possíveis.
Não é considerado válido ter somente uma metade de um par substituto. Para ser válido, deve sempre haver um substituto alto seguido de um baixo. Isso faz com que verificar um substituto seja uma questão de verificação de intervalos, que é fácil se comparada às regras complexas necessárias para detectar caracteres DBCS (sistema de caracteres de dois bytes).
Tanto o SQL Server 2000 como o SQL Server 2005 podem armazenar pares substitutos, mesmo que o UCS-2 não reconheça substitutos. O SQL Server trata os pares substitutos como dois caracteres Unicode indefinidos em vez de um único caractere. Geralmente, tais aplicativos são conhecidos como substituto neutro ou substituto seguro, o que significa que não há nenhuma capacidade intrínseca de interagir com os dados, mas, pelo menos, os dados podem ser armazenados sem perdas.
Em contraste, os aplicativos "reconhecedores de substitutos" podem não só levar em consideração pares substitutos, como processar caracteres combináveis e outros caracteres que requerem tratamento especial. Um aplicativo bem escrito pode detectar substitutos separados e recombiná-los, com apenas algumas sub-rotinas. O Microsoft Word e o Internet Explorer 5 e posterior são exemplos de aplicativos que reconhecem substitutos.
Ao trabalhar com caracteres suplementares no SQL Server, lembre-se dos seguintes pontos:
| • | Como os pares substitutos são considerados dois pontos de código Unicode separados, o tamanho de nvarchar(n) precisa ser 2 para conter um único caractere suplementar (em outras palavras, espaço para um par substituto). |
| • | Os caracteres suplementares não têm suporte para uso em metadados, como nomes de objetos de banco de dados. Em geral, o texto usado em metadados precisa seguir as regras para identificadores. Para obter mais informações, consulte Identificadores nos Manuais Online do SQL Server 2005. |
| • | As operações padrão com cadeias de caracteres não reconhecem caracteres suplementares. Operações como SUBSTRING(nvarchar(2),1,1) retornam somente o substituto alto do par de substitutos dos caracteres suplementares. A função LEN retorna a contagem de dois caracteres para cada caractere suplementar encontrado: um para o substituto alto e outro para o baixo. Entretanto, você pode criar funções personalizadas que reconheçam caracteres suplementares. O exemplo StringManipulate em Manipulação de cadeias de caracteres que reconhecem caracteres suplementares, nos Manuais Online do SQL Server 2005, demonstra como criar tais funções. |
| • | O comportamento de pesquisa e classificação de caracteres suplementares pode mudar de acordo com o agrupamento. Nos novos agrupamentos 90_ e BIN2, os caracteres suplementares são comparados corretamente, ao passo que, em agrupamentos mais antigos e agrupamentos padrão do Windows, todos os caracteres suplementares são comparados como iguais a todos os outros caracteres suplementares. Por exemplo, os agrupamentos padrão Japanese e Korean não manipulam caracteres suplementares, ao contrário do Japanese_90 e do Korean_90. |
Para obter mais informações sobre pontos de código Unicode, práticas recomendadas para projetar aplicativos que reconheçam substitutos e como trabalhar com dados Unicode, consulte Globalização passo a passo: Unicode habilitado. Para obter informações sobre intervalos de caracteres com suporte no padrão Unicode, consulte a seção Expressões regulares Unicode no Padrão técnico Unicode nº18.
Caracteres combináveis
Caracteres combináveis são aqueles usados em conjunto com outros caracteres para modificar sua aparência ou significado. Os caracteres combinados formam um único glifo. Por exemplo, os diacríticos usados em idiomas europeus são caracteres combináveis que podem aparecer como um caractere mais um diacrítico ou como um caractere pré-composto.
No .NET Framework, a seqüência de caracteres combináveis é tratada como elemento de texto, ou seja, uma unidade de texto exibida como um único caractere. Um elemento de texto é diferente de um elemento de classificação. Por exemplo, em alguns agrupamentos, as letras "CH" não são caracteres combináveis; elas são dois elementos de texto separados, mas podem ser tratadas como um elemento de classificação.
Observação As funções SQL, por outro lado, geralmente tratam caracteres combináveis da mesma forma que caracteres suplementares: Elas os processam como dois pontos de código Unicode separados. Para ver um exemplo de como criar uma função personalizada que conte de maneira mais precisa e compare caracteres suplementares, consulte o exemplo StringManipulate.
A forma como os caracteres combináveis mapeiam para elementos de classificação depende tanto do agrupamento como do padrão Unicode. Alguns caracteres combinados são sempre considerados equivalentes às suas formas de variantes, não importa quantos pontos de código diferentes eles incluam (por exemplo, uma letra latina “a” mais um diacrítico é tratada como equivalente à letra pré-composta incluindo diacrítico), ao passo que, em certos agrupamentos, é possível classificar ou comparar cadeias de caracteres de modo diferente, dependendo da presença do diacrítico.
Os caracteres combináveis foram originalmente definidos no Unicode 2.0. Para obter mais informações, consulte a seção da especificação do Unicode 4.0.1, que lida com Áreas Especiais e Caracteres de Formato. O Consórcio Unicode também publica Perguntas Freqüentes relacionadas especificamente a caracteres combináveis e seu processamento. Para obter mais informações sobre métodos para processar caracteres combináveis no.NET Framework, consulte Normalização, no Guia do Desenvolvedor do .NET Framework.
Suporte a GB18030
O GB18030 (GB18030-2000) é um padrão separado obrigatório na República Popular da China para codificar caracteres chineses. Ele especifica tanto uma página de código estendida como uma tabela de mapeamento para Unicode. Desde 01 de agosto de 2006, o suporte a esse conjunto de caracteres é oficialmente obrigatório para todos os produtos de software na República Popular da China. A conformidade com o GB18030 inclui requisitos para dar suporte a alguns idiomas que não o tinham anteriormente, como o tibetano, o mogol, o yi e o uigur.
No GB18030, os caracteres podem ser de 1, 2 ou 4 bytes. Os pares substitutos são usados para habilitar o mapeamento das seqüências de 4 bytes do GB18030 para Unicode.
O SQL Server 2005 oferece suporte a caracteres codificados com o GB18030, reconhecendo-os quando entram no servidor vindos de um aplicativo do lado do cliente. O SQL Server 2005 converte e armazena esses caracteres nativamente como Unicode. Uma vez armazenados no servidor, eles são tratados como caracteres Unicode em qualquer operação subseqüente executada neles. O GB18030 não tem uma localidade do sistema; ele possui apenas um identificador de página de código, para permitir conversões de e para o Unicode. O identificador de página de código da Microsoft para o GB18030-2000 é 54936.
Ao usar caracteres GB18030, lembre-se que eles podem ser utilizados em operações de ordenação e comparação, mas, em agrupamentos mais antigos que o SQL Server 90, as comparações se baseiam apenas nos pontos de código deles, e não em outros meios lingüisticamente significativos. Por isso, cuidado ao usar caracteres GB18030 em operações como ORDER BY, GROUP BY e DISTINCT, principalmente quando houver caracteres GB18030 e não-GB18030 incluídos na mesma operação. Para permitir comparações significativas de cadeias de caracteres que usam caracteres GB18030, utilize a nova versão do agrupamento SQL Server 90, demonstrada pelo sufixo 90 adicionado ao nome. Por exemplo, em vez do agrupamento Chinese_PRC, use Chinese_PRC_90.
Para habilitar o suporte do padrão GB18030, instale um pacote de suporte disponível no portal Ajuda e Suporte Microsoft, que inclui bibliotecas e um arquivo de fontes para dar suporte à conversão entre GB18030 e Unicode. O pacote de suporte é um binário internacional que funciona no Windows XP ou no Windows 2000. Entretanto, é necessário que o sistema tenha o suporte opcional a idiomas do Leste Asiático instalado. No Windows Vista, o suporte para o padrão GB18030 está incluído, como fontes e layouts de teclado para idiomas minoritários chineses como tibetano, mogol, yi e uigur. Esses idiomas usam a localidade Chinese (PRC).
Observação Algumas funções para converter bytes do GB18030 para caracteres Unicode, como BytesToUnicode, não têm suporte no Vista. Para fazer isso nesse sistema operacional, use a função MultiByteToWideChar.
Para obter mais informações sobre suporte para este padrão em produtos Microsoft, consulte o portal Computação e desenvolvimento global da Microsoft.
Tipos de dados no SQL Server 2005
Esta seção descreve os novos tipos de dados no SQL Server 2005 e explica questões relacionadas ao uso de tipos de dados do SQL Server 2005 para armazenar dados internacionais.
Tipos de texto não-Unicode: char, varchar, text, varchar(max)
Ao lidar com dados de texto que são armazenados no tipo de dados char, varchar, varchar(max) ou text, a limitação mais importante a ser considerada é que somente informações de uma única página de código podem ser validadas pelo sistema. (É possível armazenar dados de várias páginas de código, mas não é recomendável.) A página de código exata usada para validar e armazenar os dados depende do agrupamento da coluna. Se um agrupamento no nível de coluna não tiver sido definido, será usado o agrupamento do banco de dados. Para determinar a página de código usada para uma determinada coluna, use a função COLLATIONPROPERTY, conforme mostram os exemplos de código a seguir:
SELECT COLLATIONPROPERTY('Chinese_PRC_Stroke_CI_AI_KS_WS', 'CodePage')
936
SELECT COLLATIONPROPERTY('Latin1_General_CI_AI', 'CodePage')
1252
SELECT COLLATIONPROPERTY('Hindi_CI_AI_WS', 'CodePage')
0
O último exemplo retorna 0 (Unicode) como a página de código para Hindi. Esse exemplo ilustra o fato de que muitas localidades, como Georgian e Hindi, não possuem páginas de código, já que são agrupamentos somente Unicode. Como esses agrupamentos não são apropriados para colunas que usam o tipo de dados char, varchar ou text, alguns agrupamentos têm sido preteridos. Para obter uma lista de agrupamentos disponíveis e quais deles são somente Unicode, consulte Configurações de agrupamentos na instalação nos Manuais Online do SQL Server 2005.
Importante No SQL Server 2005, use o tipo de dados varchar(max) em vez de text. O tipo de dados text será removido em uma futura versão do Microsoft SQL Server. Para obter mais informações, consulte Usando tipos de dados de valor grande nos Manuais Online do SQL Server 2005.
Quando os dados Unicode precisam ser inseridos em colunas não-Unicode, elas são convertidas do Unicode internamente com o uso da API WideCharToMultiByte e da página de código associada ao agrupamento. Se um caractere não puder ser representado naquela página de código, ele será substituído por um ponto de interrogação (?). Por isso, a aparência de pontos de interrogação aleatórios em seus dados é uma boa indicação de que os dados foram corrompidos devido a uma conversão não especificada. Também é uma boa indicação de que o seu aplicativo pode tirar proveito da conversão para um tipo de dados Unicode.
Se você usar um literal de cadeia de caracteres de um tipo não-Unicode para o qual não haja suporte no agrupamento, a cadeia será convertida primeiro com o uso da página de código padrão do banco de dados, que deriva do agrupamento padrão do banco de dados.
Outro problema com o qual você pode se deparar é a incapacidade de armazenar dados quando nem todos os caracteres aos quais você deseja dar suporte estão contidos na página de código. Em muitos casos, o Windows considera uma determinada página de código como "o melhor ajuste", o que significa que não há nenhuma garantia de que você possa se basear nela para manipular todo o texto – ela é simplesmente a melhor opção disponível. Um exemplo disso é a escrita arábica: ela dá suporte a uma série de idiomas, como baluchi, bérber, farsi, kashmiri, cazaque, kirghiz, curdo, pashto, sindi, uigur, urdu, etc. Todos esses idiomas têm caracteres adicionais além daqueles no idioma arábico, conforme definido na página de código do Windows 1256. Se você tentar armazenar esses caracteres extras em uma coluna não-Unicode que tenha o agrupamento Arabic, os caracteres serão convertidos em pontos de interrogação.
Tipos de texto Unicode: nchar, nvarchar, nvarchar(max), ntext
A especificação SQL-92 define os tipos de dados prefaciados com "N" (significando os tipos de dados "nacionais"), mas não requer especificamente que os tipos de dados sejam usados para Unicode. A definição real desses tipos de dados é deixada para o desenvolvedor ou a plataforma do banco de dados. No SQL Server 2000 e no SQL Server 2005, esses tipos de dados são definidos como equivalentes ao UCS-2, que é uma codificação Unicode. Entretanto, ao trabalhar com outros servidores de banco de dados, é importante saber que os tipos de dados "N" não significam especificamente Unicode. A decisão de definir os tipos de dados "N" como Unicode é específica para o Microsoft SQL Server.
O tipo de dados nvarchar(max), que é novo no SQL Server 2005, contém até 2 gigabytes (GB) de dados e é a alternativa preferida para o tipo de dados ntext.
Importante No SQL Server 2005, use o tipo de dados nvarchar(max) em vez de ntext. O tipo de dados ntext será removido em uma futura versão do Microsoft SQL Server. Para obter mais informações, consulte Usando tipos de dados de valor grande nos Manuais Online do SQL Server 2005.
Para o armazenamento de scripts complexos, como Hindi e Tamil, verifique se os dados estão na ordem apropriada. Muitos idiomas, como o tâmil, especificam que certas letras precisam ser reordenadas quando o texto é processado. Por isso, a ordem lógica do texto quando ele é armazenado na memória pode ser diferente da ordem visual na qual ele será visto em uma interface do usuário. Os dados devem sempre ser armazenados na ordem lógica apropriada para qualquer idioma de script complexo, o que inclui todos os idiomas índicos: arábico, farsi, hebraico e muitos outros. O processamento real desses dados é uma questão separada (consulte a seção Dados multilíngües na interface do usuário deste artigo).
Embora as colunas "N" possam dar suporte a dados de qualquer idioma ou combinação de idiomas, você só pode escolher um Agrupamentos deste artigo. Nenhuma das limitações de página de código mencionadas anteriormente neste artigo aplicam-se a colunas Unicode.
No SQL Server 2005, é possível criar funções adicionais para aprimorar o comportamento de agrupamentos e a manipulação de cadeias com caracteres suplementares. O exemplo StringManipulate para o Microsoft SQL Server 2005 demonstra o processamento de cadeias que reconhecem caracteres suplementares. Esse exemplo mostra como implementar cinco funções de cadeia de caracteres Transact-SQL que fornecem as mesmas funções de manipulação de cadeias que as funções de cadeias internas, mas com a capacidade adicional de reconhecer caracteres suplementares para manipular cadeias de caracteres suplementares e Unicode.
Tipo de dados CLR
O Microsoft SQL Server permite estender o sistema de tipos SQL definindo um tipo de dados personalizado para uso na programação do SQL Server. Esses tipos definidos pelo usuário são adequados para a criação de tipos numéricos estendidos e de moeda, tempo e data personalizados, ou para dados codificados ou criptografados.
Um tipo definido pelo usuário (UDT) pode ser usado para definir o tipo de uma coluna em uma tabela ou um parâmetro de rotina ou de variável na linguagem Transact-SQL. Uma instância de um tipo definido pelo usuário pode ser uma coluna em uma tabela, uma variável em um lote, uma função ou procedimento armazenado ou um argumento de uma função ou procedimento armazenado. Um tipo definido pelo usuário é implementado como classe gerenciada em uma das linguagens CLR e depois registrado com o SQL Server. Para obter informações sobre como implementar um tipo definido pelo usuário usando o Visual Basic ou o Microsoft Visual C#, consulte Codificando tipos definidos pelo usuário nos Manuais Online do SQL Server 2005.
Você pode usar tipos definidos pelo usuário para estender o sistema de tipos escalares do servidor, permitindo o armazenamento de objetos CLR em um banco de dados do SQL Server. Os UDTs podem conter vários elementos e ter comportamentos especiais definidos por você. Isso os diferencia do tipo de dados de alias tradicional, que consiste em um único tipo de dados de sistema do SQL Server. Por exemplo, o exemplo UDT Currency fornecido nos Manuais Online do SQL Server 2005 dá suporte à distribuição de quantias em dinheiro no sistema monetário de uma determinada cultura. Você precisa definir dois campos: um valor string para CultureInfo, que especifica a origem da moeda (por exemplo, en-us), e um valor decimal para CurrencyValue, para representar a quantia em dinheiro.
Como os UDTs são acessados pelo sistema como um todo, seu uso para tipos de dados complexos pode afetar negativamente o desempenho. Geralmente, dados complexos são mais bem modelados com o uso de tabelas e linhas tradicionais. Os Manuais Online do SQL Server 2005 contêm diversos exemplos que demonstram como criar e trabalhar com UDTs personalizados. O exemplo UTF8String para o SQL Server 2005 demonstra como implementar um tipo de dados definido pelo usuário que estende o sistema de tipos do banco de dados para fornecer armazenamento para valores codificados com UTF-8. O novo tipo também implementa código para converter cadeias de caracteres Unicode de e para UTF-8. Para obter detalhes, consulte Tipo de dados definidos pelo usuário (UDT) para cadeias de caracteres UTF-8 nos Manuais Online do SQL Server 2005.
Para ver outros exemplos, consulte Exemplos de programabilidade CLR nos Manuais Online do SQL Server 2005.
Tipo de dados XML
O tipo de dados XML permite armazenar um documento ou fragmento de XML em bancos de dados do SQL Server. Instâncias do tipo de dados XML podem ser colunas em uma tabela, argumentos de funções ou procedimentos armazenados ou variáveis em uma função ou procedimento armazenado. Além disso, o tipo de dados XML pode ser especializado indicando um esquema XML associado que fornece tanto restrições de validação como informações sobre tipos para os dados da instância XML.
Você executa operações em uma instância de um tipo de dados XML usando métodos de consulta XML internos. Esses métodos aceitam consultas e instruções de manipulação de dados que são adequadas para dados XML. É possível então especificar consultas (XQuery) comparando-as com o XML armazenado na coluna ou variável do tipo de dados XML e aplicar atualizações (usando insert, update ou delete) na instância XML. Também é possível usar um XSD para criar um índice para a coluna XML, o que melhorará o desempenho da consulta.
Para obter mais informações sobre o tipo de dados xml e os recursos no SQL Server 2005 para dar suporte à manipulação de dados XML, consulte a seção Suporte a XML no SQL Server 2005 deste artigo.
Tipos de data/hora: datetime, smalldatetime
Os tipos de dados de data e hora usados no SQL Server 2000 e no SQL Server 2005 têm as seguintes definições:
datetime
Dados de data e hora no calendário gregoriano de 01 de janeiro de 1753 até 31 de dezembro de 9999, com uma precisão de um trecentésimo de segundo (equivalente a 3,33 milissegundos ou 0,00333 segundos).
smalldatetime
Dados de data e hora no calendário gregoriano de 01 de janeiro de 1900 até 06 de junho de 2079, com a precisão do minuto. Valores smalldatetime iguais ou menores que 29.998 segundos são arredondados para menos até o minuto mais próximo; valores iguais ou maiores que 29.999 segundos são arredondados para mais até o minuto mais próximo.
O Microsoft SQL Server rejeita dados fora desses intervalos A data real é armazenada internamente como dois números inteiros que representam a data e hora em questão (números inteiros de 4 bytes para datetime e de 2 bytes para smalldatetime).
Os dados armazenados não representam a hora local ou a UTC e não contêm informações sobre fuso horário. Se você precisar converter datas para UTC, poderá usar uma das funções de data UTC. A UTC atual deriva da hora local atual e da configuração de fuso horário no sistema operacional do computador no qual a instância do Microsoft SQL Server está sendo executada. Como o valor não tem formatação específica de localidade intrínseca, o desenvolvedor é quem define as conversões conforme necessário. O SQL Server dá suporte a diferentes conversões específicas de localidade que podem ser executadas no servidor em vez de usar soluções personalizadas dos desenvolvedores. Esses estilos de data podem ser acessados por meio da função CONVERT, que adota um tipo de dados, uma expressão e um estilo opcional, como mostra a tabela a seguir.
| Com século | Sem século | Padrão | Entrada (datetime) e Saída (text) |
0 ou 100 | - | Padrão | mês dd aaaa hh:miAM (ou PM) |
101 | 1 | Estados Unidos | mm/dd/aa |
102 | 2 | ANSI | aa.mm.dd |
103 | 3 | Inglês/Francês | dd/mm/aa |
104 | 4 | Alemão | dd.mm.aa |
105 | 5 | Italiano | dd-mm-aa |
106 | 6 | - | dd mês aa |
107 | 7 | - | Mês dd, aa |
108 | 8 | - | hh:mm:ss |
9 ou 109 | - | Padrão + milissegundos | mês dd aaaa hh:mi:ss:mmmAM (ou PM) |
110 | 10 | Estados Unidos | mm-dd-aa |
111 | 11 | Japão | aa/mm/dd |
112 | 12 | ISO | aammdd |
13 ou 113 | - | Padrão europeu + milissegundos | dd mês aaaa hh:mm:ss:mmm(24h) |
114 | 14 | - | hh:mi:ss:mmm(24h) |
20 ou 120 | - | ODBC canônico | aaaa-mm-dd hh:mi:ss(24h) |
21 ou 121 | - | ODBC canônico + milissegundos | aaaa-mm-dd hh:mi:ss.mmm(24h) |
126 | - | ISO8601 (sem espaços) | aaaa-mm-dd Thh:mm:ss:mmm |
130 | - | Kuwait (Islâmico) | dd mês aaaa hh:mi:ss:mmmAM |
131 | - | Kuwait (Islâmico) | dd/mm/aa hh:mi:ss:mmmAM |
O exemplo a seguir mostra como a função CONVERT é usada para representar a data atual em um estilo especificado:
SELECT CONVERT(char, GETDATE(), 100) AS [100] RETURNS: Aug 16 2000 11:50AM
Você pode então converter os dados de uma cadeia de caracteres para um valor de dados praticamente da mesma forma:
SELECT CONVERT(datetime, 'Aug 16 2000 11:50AM', 100) AS [100] RETURNS: 100 2000-08-16 11:50:00.000
Se você converter datas em Style 130 (Kuwait ou Islâmico) para um tipo de dados char, os dados poderão ser corrompidos caso o agrupamento não seja um dos agrupamentos Arabic que usam página de código 1256 para conversões Unicode. Por exemplo, a Figura 1 mostra uma coluna que foi convertida para char e uma segunda coluna que foi convertida para nchar. Neste exemplo, o computador cliente usa a localidade EN-US. Por isso, quando você tenta usar o tipo de dados char, os caracteres arábicos são convertidos em pontos de interrogação, enquanto que, se você usar o tipo de dados nchar, eles serão exibidos.
Figura 1. Usando CONVERT com dados de hora/data
Entretanto, mesmo se a cadeia de caracteres representada com o uso de nchar ainda não estiver formatada corretamente, ela o será em um computador cliente arábico, por causa das limitações no Editor de Consulta. A Figura 2 mostra como deve ser a aparência da cadeia de caracteres de data Hijri atual.
Figura 2. Cadeia de caracteres de data Hijri
A razão pela qual o arábico não pode ser processado corretamente é que escritas complexas, como o arábico, têm regras de formação que controlam a maneira como os dados são processados. No caso de idiomas bidirecionais (BIDI) como o hebraico, o formato faz com que todos os dados sejam revertidos. No caso do arábico, o formato tem um efeito mais marcado, pois as formas atuais das letras podem mudar dependendo das letras ao redor. Esse problema não acontece em versões do Windows posteriores ao Windows 2000 ou em qualquer versão anterior do Windows habilitada para o arábico.
Além disso, a cadeia de caracteres de data que é retornada pode provocar problemas nos casos bidirecionais onde ela é necessária, pois as regras para o layout do texto bidirecional usado por um aplicativo, como o Internet Explorer, faz com que a data apareça como mostra a Figura 3.
Figura 3. Exemplo de cadeia de caracteres de data bidirecional
Obviamente, esta ordem visual (dd hh:mi:ss aaaa mês :) não é a esperada. O problema pode ser considerado uma limitação geral do estilo 130 a função CONVERT. É possível contornar esse problema adicionando o caractere de controle Unicode apropriado na frente da cadeia de caracteres, como na seguinte consulta:
SELECT NCHAR(8207) + CONVERT(nchar, GETDATE(), 130)
A função NCHAR retorna um caractere baseado no ponto de código Unicode passado. 8207 ou 0x200F hexadecimal é o RLM (Right-to-Left Marker), e isso faz com que a cadeia de caracteres seja exibida corretamente.
Desempenho e espaço de armazenamento
Se você definir uma coluna usando um dos tipos de dados Unicode, poderá ter os seguintes problemas relacionados a velocidade e espaço de armazenamento.
Maior espaço de armazenamento
Os tipos de dados Unicode usam dois ou mais bytes por caractere, enquanto os não-Unicode usam um byte para todo texto não-DBCS e dois bytes para idiomas asiáticos que usam DBCS. Por isso, a menos que os seus dados usem uma das páginas de código asiáticas, quando você converter para Unicode, usará duas vezes mais espaço para armazenar os dados. Os requisitos para maior espaço de armazenamento precisam ser considerados quando você atualizar bancos de dados existentes ou quando estiver decidindo sobre os tipos de dados apropriados para um novo projeto. Se você estiver armazenando dados somente em uma coluna que esteja em uma única página de código (não-asiática), talvez seja melhor não usar o Unicode para poder salvar espaço em disco e na memória. Entretanto, as vantagens da conversão Unicode geralmente superam os impactos no armazenamento.
Observação Ao armazenar dados DBCS asiáticos, o método de codificação UCS-2 usado pelo SQL Server 2005 tende a ser mais eficiente que o método UTF-8 usado por outros programas de banco de dados. Isso porque o UTF-8 usa três bytes para armazenar a maioria dos caracteres de idiomas asiáticos, enquanto o UCS-2 usa apenas dois (com exceção dos caracteres suplementares e dos combináveis). Por outro lado, para idiomas não-DBCS, como os caracteres baseados em ASCII, o UTF-8 geralmente usa um byte por caractere, enquanto o UCS-2 usa dois.
Questões sobre velocidade
O efeito do uso de tipos de dados Unicode em desempenho é complexo. Você deve considerar as seguintes questões:
| • | Se você estiver executando o Windows XP, o Windows Server 2003 ou o Windows Vista, o sistema operacional espera dados Unicode; por isso, em muitos casos, as colunas não-Unicode precisam ser convertidas quando você exibe dados ou usa os serviços do sistema operacional. |
| • | Quando você está lidando com um formato de dados DBCS nativo, talvez seja necessário um tempo extra para carregar a quantidade maior de dados. |
| • | Se você estiver trabalhando entre instâncias, entre produtos do servidor de banco de dados ou trocando dados com outros aplicativos, o número de conversões pode afetar o desempenho. |
| • | Se você estiver lidando com idiomas asiáticos, o Unicode é mais rápido do que a página de código DBCS específica para o idioma. Isso porque os dados DBCS não têm largura fixa; eles são uma mistura de caracteres de um e dois bytes. |
| • | Se você estiver lidando com idiomas não-asiáticos, a classificação de dados Unicode pode ser mais lenta que a de não-Unicode. |
| • | A binária é a ordem de classificação mais rápida e faz a diferenciação de maiúsculas/minúsculas, mas pode gerar ordens de classificação inesperadas. Se uma ordem de classificação binária for selecionada, as opções para diferenciação de maiúsculas/minúsculas, de largura de caracteres, de caracteres com/sem acento ou de caracteres tipo kana não estarão disponíveis. |
Importante Para avaliar o desempenho de forma realista, você deve testar tanto cenários Unicode como não-Unicode.
Migração de informações de metadados em tabelas de sistema
As tabelas de sistema no SQL Server 2005 armazenam todos os dados nas tabelas de sistema – inclusive identificadores para objetos – como Unicode. Isso minimiza os problemas que podem ocorrer com diferentes agrupamentos entre colunas e bancos de dados.
Se você estiver migrando do SQL Server 2000 para o SQL Server 2005, a única alteração significativa é que o SQL Server 2000 usa o padrão Unicode 2.0 para a lista de caracteres válidos em identificadores, enquanto que o SQL Server 2005 oferece suporte à versão 3.2 do Padrão Unicode.
Você pode atualizar diretamente instâncias do SQL Server 2000 Service Pack 3 (SP3) ou posterior e instâncias do SQL Server 7.0 SP4 ou posterior para o SQL Server 2005. Também é possível executar a maioria das operações de atualização por meio da instalação. Entretanto, alguns componentes oferecem suporte ou requerem migração de aplicativos ou soluções após a execução da instalação.
Agrupamentos
A ordem de classificação é fundamental, mas quase sempre é minimizada na definição de banco de dados. Os usuários tendem a achar natural a classificação em seu próprio alfabeto. Entretanto, alguns idiomas, como o grego, o russo e o tailandês, usam alfabetos diferentes. Outros, como o japonês, usam vários alfabetos, com regras complexas de ordenação. Mesmo nos idiomas europeus, há uma grande diferença na forma como caracteres individuais são manipulados. Por exemplo, os usuários de espanhol esperam que a combinação de letras "ch" seja classificada como um único caractere após a letra "h".
A classificação básica funciona por meio de agrupamentos, que controlam ordens de classificação, entre outros comportamentos. A classificação pode ser otimizada com a criação de índices.
A classificação funciona em conjunto com uma técnica conhecida como normalização de cadeias de caracteres. Esse tipo de normalização é diferente do sentido da palavra ao qual os desenvolvedores de bancos de dados estão acostumados. A normalização de cadeias de caracteres refere-se ao método de comparar duas cadeias para que elas possam ser classificadas. Por exemplo, você pode especificar se tipos de kana diferentes devem ser tratados como equivalentes ou se os acentos devem ser ignorados.
Para colunas não-Unicode, o agrupamento tem um segundo significado que é muito importante: ele especifica a página de código para os dados e, assim, determina quais caracteres podem ser representados. Os dados podem ser movidos entre colunas Unicode sem necessidade de conversão especial ou mapeamentos de caracteres. Os dados movidos entre colunas não-Unicode quase sempre têm erros, são corrompidos ou não podem ser exibidos.
Agrupamentos no SQL Server 6.5 e versões anteriores
Nas versões 6.5 e anteriores do SQL Server, os agrupamentos eram usados para especificar a página de código para o uso de idiomas em geral. Havia várias limitações relacionadas a diferentes ordens de classificação. Por exemplo, você só podia dar suporte a idiomas da Europa Ocidental se usasse Latin-1. Os agrupamentos também limitavam o número de localidades diferentes que podiam ser representadas em uma única instância do SQL Server. Em outras palavras, só era possível armazenar ou exibir o idioma usado em uma região específica. Para usar um idioma diferente, você precisava configurar um banco de dados separado ou até mesmo um servidor separado.
Essas questões aplicam-se também ao agrupamento de campos não-Unicode em versões posteriores do SQL Server.
Agrupamentos no SQL Server 7.0
O SQL Server 7.0 forneceu um agrupamento Unicode e um não-Unicode por servidor. Os agrupamentos não-Unicode foram definidos como uma combinação de uma página de código e uma ordem de classificação. Em geral, cada página de código pode oferecer suporte a mais de uma ordem de classificação; por exemplo, idiomas latinos normalmente permitem classificação com e sem diferenciação de maiúsculas e minúsculas. O chinês simplificado permite a classificação por número de traços e classificações fonéticas.
Em um agrupamento do Unicode, qualquer caractere de qualquer idioma pode ser incluído na coluna, e os diversos agrupamentos fornecidos foram desenvolvidos para garantir que qualquer diferença específica de agrupamento seja tratada adequadamente. Em outras palavras, você escolhe o "melhor ajuste" para dar aos usuários os dados que eles esperam. Por exemplo, o agrupamento geral do Unicode permite classificar dados em farsi.
Um agrupamento do Unicode consiste em uma localidade e diversos estilos de comparação. As localidades geralmente são nomeadas depois dos países e das áreas culturais. Elas classificam caracteres de acordo com o padrão nessa área. O agrupamento do Unicode ainda fornece uma ordem de classificação para todos os caracteres no padrão Unicode, mas é dada precedência à localidade especificada. Qualquer localidade que não tenha um agrupamento do Unicode exclusivo e com suporte deve usar o Agrupamento Geral do Unicode.
A ordem de classificação geral do Unicode manipula corretamente não apenas os dados, mas também a classificação de africânes, albanês, basco, bielo-russo, búlgaro, inglês, faroês, farsi, georgiano (tradicional), grego, hebraico, híndi, indonésio, malaio, russo, sérvio, suaíle e urdu.
Uma alteração importante no SQL Server 7.0 foi a provisão de um modelo independente de sistema operacional para comparação de cadeias de caracteres, a fim de que os agrupamentos entre todos os sistemas operacionais – desde o Windows 95 até o Windows 2000 – fossem consistentes. Esse código de comparação de cadeias de caracteres baseou-se no mesmo código que o Windows 2000 usa para sua normalização de cadeias de caracteres e está encapsulado para ser o mesmo em todos os computadores e em todas as versões do SQL Server.
Agrupamentos no SQL Server 2000
No SQL Server 2000, o modelo de agrupamento foi alterado para eliminar inconsistências entre os dois sistemas diferentes de agrupamentos: do Windows e do SQL Server. Foi necessário um modelo mais flexível para lidar com todos os novos requisitos para agrupamentos. Novos agrupamentos também foram necessários no SQL Server 2000 para manipular a página de código de colunas não-Unicode.
Para atender a essas necessidades, foi desenvolvido um modelo consistente para manipular tanto classificações Unicode como não-Unicode. Cada um dos agrupamentos foi combinado com sufixos para ajudar a definir se o agrupamento faz diferenciação de maiúsculas/minúsculas, de largura de caracteres, de caracteres com/sem acento e de caracteres tipo kana. O Apêndice A contém uma tabela que lista os sufixos. Esses 17 sufixos, combinados corretamente aos 40 idiomas com suporte no SQL Server 2000, criaram um total de 680 agrupamentos do Windows.
Os nomes de idiomas usados para os agrupamentos foram arbitrários e escolhidos para representar cada página de código com suporte exclusivo para dados não-Unicode e uma ordem de classificação para todos os dados. Em muitos casos, vários idiomas puderam ser totalmente representados em uma única página de código ou processados pela mesma ordem de classificação usada por outro idioma. Nesses casos, os idiomas adicionais foram removidos da lista.
Agrupamentos no SQL Server 2005
O SQL Server 2005 dá suporte a todos os idiomas para os quais há suporte nos sistemas operacionais Microsoft Windows. Isso significa que o SQL Server 2005 adicionou suporte para agrupamentos novos e atualizados no Windows Server 2003 e no Windows XP. (Esses agrupamentos são instalados como parte da instalação do SQL Server 2005. Você controla a opção de agrupamento para o servidor e o banco de dados durante a instalação. As atualizações no sistema operacional não afetam os agrupamentos usados no SQL Server.)
Uma parte importante dos novos agrupamentos foram os agrupamentos do Leste Asiático que dão suporte a caracteres suplementares. O suporte também foi adicionado para comparação de cadeias de caracteres de suplementares, com base em pontos de código, e um sinalizador binário (BIN2) foi introduzido para permitir comparações entre pontos de código verdadeiros.
Os agrupamentos binários classificam e comparam dados no SQL Server com base no padrão de bits de cada caractere. Cada agrupamento binário no SQL Server mapeia para uma determinada localidade de idioma e página de código ANSI, além de executar classificações de dados que fazem diferenciação de maiúsculas/minúsculas e de caracteres com/sem acento. Os agrupamentos binários fornecem as classificações de dados mais rápidas.
A opção Binary (_BIN) classifica e compara dados em tabelas do SQL Server com base nos padrões de bits definidos para cada caractere. A ordem de classificação binária faz diferenciação de maiúsculas/minúsculas e de caracteres com/sem acento. Ela também é a ordem de classificação mais rápida. Se esta opção não estiver selecionada, o SQL Server segue as regras de classificação e comparação conforme definido nos dicionários para o alfabeto ou idioma associado.
A opção de ponto de código binário (_BIN2) classifica e compara dados em tabelas do SQL Server com base em pontos de código Unicode para dados Unicode. Para dados não-Unicode, o ponto de código binário usará comparações idênticas a classificações binárias. A vantagem de usar uma ordem de classificação de ponto de código binário é que não há necessidade de reclassificar os dados em aplicativos que comparam dados do SQL Server classificados. Em decorrência disso, uma ordem de classificação de ponto de código binário proporciona um desenvolvimento de aplicativos mais simples e um possível aumento no desempenho.
O Apêndice E contém uma lista de agrupamentos que foram atualizados no SQL Server 2005. A menos que você precise de compatibilidade com versões anteriores do SQL Server 2000, é melhor usar os agrupamentos atualizados.
Os agrupamentos no SQL Server 2005 incluem os seguintes tipos de agrupamento: do Windows e do SQL Server.
Agrupamentos do Windows
Os agrupamentos do Windows definem regras para armazenar dados de caracteres baseados em uma localidade do Windows associada. (Existem mais localidades do Windows do que agrupamentos do SQL Server.) As regras básicas de agrupamento do Windows especificam qual alfabeto ou idioma será usado quando a classificação de dicionário for aplicada, bem como a página de código usada para armazenar dados de caracteres não-Unicode. No SQL Server, os agrupamentos do Windows são combinados com uma série de sufixos para definir adicionalmente regras de classificação e comparação com base na diferenciação de maiúsculas/minúsculas, de caracteres com/sem acento, de caracteres kana e de largura de caracteres. O nome completo do agrupamento do Windows é composto pelo designador de agrupamento e pelos estilos de comparação.
Em um agrupamento do Windows, a comparação e a classificação de dados não-Unicode é implementada com o uso do mesmo algoritmo que os dados Unicode. Isso fornece consistência em todos os tipos de dados no SQL Server e permite que os desenvolvedores classifiquem cadeias de caracteres em seus aplicativos usando as mesmas regras utilizadas pelo SQL Server – ou seja, chamando a função CompareStringW da API do Microsoft Win32.
Agrupamentos binários
Os agrupamentos binários classificam dados com base na seqüência de valores codificados definida pela localidade e pelo tipo de dados. Um agrupamento binário no SQL Server define a localidade do idioma e a página de código ANSI a ser usada, impondo uma ordem de classificação binária. Os agrupamentos binários são úteis para obter melhor desempenho dos aplicativos devido à sua relativa simplicidade. Para tipos de dados não-Unicode, as comparações de dados se baseiam nos pontos de código definidos na página de código ANSI. Para tipos de dados Unicode, as comparações de dados se baseiam nos pontos de código Unicode. Para agrupamentos binários em tipos de dados Unicode, a localidade não é considerada em classificações de dados. Por exemplo, Latin_1_General_BIN e Japanese_BIN2 geram resultados de classificação idênticos quando usados em dados Unicode. Isso porque o agrupamento compara Unicode como Unicode e dados não-Unicode como binários.
No SQL Server 2000, os agrupamentos binários executaram uma comparação incompleta de ponto de código a ponto de código para dados Unicode. O primeiro caractere foi comparado como WCHAR, seguido de uma comparação byte por byte. Para garantir a compatibilidade com versões anteriores, a semântica dos agrupamentos binários existentes não será alterada.
Os agrupamentos binários no SQL Server 2005 incluem tanto o agrupamento BIN anterior como um novo conjunto de agrupamentos de comparação pura de pontos de código. Os clientes podem optar por migrar para os novos agrupamentos binários a fim de tirar proveito de comparações verdadeiras de ponto de código e devem utilizar os novos agrupamentos binários no desenvolvimento de novos aplicativos. O novo sufixo BIN2 identifica nomes de agrupamentos que implementam a semântica do novo agrupamento de ponto de código. Além disso, um novo sinalizador de comparação é adicionado correspondendo ao BIN2 para a nova classificação binária.
O SQL Server recomenda automaticamente um agrupamento padrão baseado na localidade do sistema. Você deve alterar as configurações de um agrupamento padrão do Windows somente se for necessário que a instalação do SQL Server coincida com as configurações do agrupamento usadas por outra instância do SQL Server ou que elas coincidam com a localidade do sistema Windows de outro computador.
Se você precisar manipular caracteres suplementares, altere o agrupamento padrão para um dos novos agrupamentos que dão suporte a operações de comparação e classificação em caracteres suplementares. Essas comparações se baseiam somente em pontos de código, e não em outros meios lingüisticamente significativos. Somente as versões de agrupamento 90, que são demonstradas pelo sufixo 90 adicionado aos nomes, dão suporte a essas operações. Por exemplo, em vez do agrupamento Japanese, use Japanese_90. Se você não usar um agrupamento que reconheça caracteres suplementares, cuidado ao usar caracteres suplementares em operações como ORDER BY, GROUP BY e DISTINCT, principalmente quando houver caracteres suplementares e não-suplementares incluídos na mesma operação.
Agrupamentos do SQL Server
Os agrupamentos SQL Server fornecem compatibilidade de ordem de classificação com versões anteriores do SQL Server. (Para obter uma lista completa de agrupamentos do SQL Server, consulte Nome de agrupamento do SQL nos Manuais Online do SQL Server 2005.) Os agrupamentos do SQL Server são baseados em ordens de classificação do SQL Server herdadas para dados não-Unicode – por exemplo, os tipos de dados char e varchar – definidos pelo SQL Server. As regras da classificação de dicionário para dados não-Unicode não são compatíveis com nenhuma rotina de classificação fornecida pelos sistemas operacionais Windows, mas a classificação de dados Unicode é compatível com uma versão específica das regras de classificação do Windows. Como os agrupamentos do SQL Server usam regras de comparação diferentes para dados Unicode e não-Unicode, talvez você receba resultados diferentes para comparações dos mesmos dados, dependendo do tipo de dados subjacente.
Quando você atualiza uma instância do SQL Server, os agrupamentos dele podem ser especificados para compatibilidade com outras instâncias já existentes. Como o agrupamento padrão de uma instância do SQL Server é definido durante a instalação, é importante ter cuidado ao especificar as configurações de agrupamentos quando:
| • | O código do aplicativo depender, de alguma forma, do comportamento de agrupamentos anteriores do SQL Server. |
| • | Você for usar replicação do SQL Server 2005 com instalações existentes do SQL Server 6.5 ou SQL Server 7.0. |
| • | Você precisar armazenar dados de caracteres que refletem vários idiomas. |
Se você tiver uma combinação de colunas Unicode e não-Unicode no banco de dados, deve usar principalmente agrupamentos do Windows, que se aplicam a regras de classificação baseadas no Unicode tanto para dados Unicode como não-Unicode. Isso significa que o SQL Server converte internamente dados não-Unicode em Unicode para executar operações de comparação. Essa conversão fornece consistência em todos os tipos de dados no SQL Server e permite que os desenvolvedores classifiquem cadeias de caracteres em seus aplicativos que usam as mesmas regras do SQL Server.
Os agrupamentos do SQL, por outro lado, aplicam regras de classificação não-Unicode a dados não-Unicode e regras de classificação Unicode a dados Unicode, usando um agrupamento do Windows correspondente para os dados Unicode. Essa diferença pode gerar resultados inconsistentes para comparações dos mesmos caracteres. Por isso, se você tem uma combinação de colunas Unicode e não-Unicode no banco de dados, todas devem ser definidas com o uso de agrupamentos do Windows para que as mesmas regras de classificação sejam usadas em dados Unicode e não-Unicode.
Compatibilidade com versões anteriores em agrupamentos
O agrupamento binário BIN fornecido no SQL Server 2000 executou uma comparação de ponto de código a ponto de código para dados Unicode. Esse agrupamento comparou o primeiro caractere com WCHAR, seguido de uma comparação byte por byte. Isso poderia fazer os dados de caracteres Unicode serem classificados de maneira inesperada.
Para garantir compatibilidade com versões anteriores, a semântica dos agrupamentos binários existentes não será alterada. Entretanto, a funcionalidade pode ter sido substituída por agrupamentos mais recentes. O Apêndice lista agrupamentos que foram preservados para compatibilidade com versões anteriores com o SQL Server 2000 ou o SQL Server 7.0.
Para obter informações sobre agrupamentos em um banco de dados, você pode usar os seguintes modos de exibição do sistema:
| Modo de exibição de catálogo | Descrição |
sys.databases | Retorna informações sobre o agrupamento de um banco de dados. |
sys.columns | Retorna informações sobre o agrupamento de uma coluna de uma tabela ou modo de exibição. |
COLLATIONPROPERTY | Retorna informações sobre agrupamentos no SQL Server 2005. Você pode passar o valor CodePage (ou LCID), que retorna a identificação de localidade do Windows, ou Null para agrupamentos do SQL. Também pode especificar ComparisonStyle do Windows (retorna Null para agrupamentos tanto Binary como do SQL). ComparisonStyle pode ser usado para verificar se existe uma equivalência entre a normalização da cadeia de caracteres no Windows e no SQL Server para o agrupamento do Windows. |
fn_helpcollations | Retorna uma lista de agrupamentos disponíveis no SQL Server 2005. SELECT * FROM ::fn_helpcollations() No SQL Server 2005, esta consulta retorna 1.011 agrupamentos. (No SQL Server 2000, 753 agrupamentos.) |
SERVERPROPERTY | Retorna o agrupamento associado ao servidor. SELECT CONVERT(char, SERVERPROPERTY('collation')) |
DATABASEPROPERTYEX | Determina o agrupamento de um banco de dados, por exemplo: SELECT CONVERT(char, DATABASEPROPERTYEX('pubs', 'collation')) |
Agrupamentos adicionais não podem ser acrescentados, a menos que o sejam em service packs ou futuras versões.
Agrupamentos e classificação de dados
Como regra geral, todo agrupamento definido no SQL Server em uma coluna Unicode classificará todos os caracteres Unicode definidos. Entretanto, existem muitos agrupamentos diferentes porque há muitas diferenças na forma como os dados podem ser classificados. Um bom exemplo é a classificação Georgiano moderno. Embora a classificação tradicional de texto georgiano coloque todos os caracteres em uma ordem específica, no uso moderno é comum colocar no final certos caracteres usados raramente. Esses caracteres são HE (), HEI (), WE () e HAR (). Portanto, existem duas maneiras de classificar o alfabeto Georgiano: tradicional e moderno.
Figura 4. Ordem de classificação Traditional Georgian
Figura 5. Ordem de classificação Modern Georgian
A existência desse agrupamento não impede que outros dados Unicode sejam classificados de acordo com a ordem de classificação fornecida no agrupamento Latin1_General. Todos os agrupamentos, na verdade, classificam o Georgiano na forma tradicional, com exceção dos agrupamentos Georgian_Modern_Sort. Em outras palavras, as mesmas regras gerais aplicam-se a todos os agrupamentos; somente as exceções mudam entre os agrupamentos.
Níveis de agrupamento
O SQL Server 2005 dá suporte à configuração de agrupamentos nos seguintes níveis de uma instância do SQL Server 2005:
| • | Nível de servidor |
| • | Nível de banco de dados |
| • | Nível de coluna |
| • | Nível de expressão |
Esta seção explica esses níveis de agrupamento e a forma como eles interagem quando vários agrupamentos são usados.
Agrupamentos especificados no nível de servidor
O agrupamento padrão de uma instância do SQL Server é definido durante a instalação e se torna o padrão dos bancos de dados do sistema. Depois que um agrupamento tiver sido atribuído a qualquer objeto que não seja uma coluna ou um banco de dados, só é possível alterar o agrupamento descartando e recriando o objeto. Em vez de alterar o agrupamento padrão de uma instância do SQL Server, você pode especificá-lo quando criar um novo banco de dados ou uma nova coluna de banco de dados.
Nas versões anteriores, o agrupamento era sempre definido no nível de servidor e, em muitos casos, era o único agrupamento que você precisava definir. O agrupamento do servidor funciona como padrão sempre que um novo banco de dados é criado no servidor, a menos que você defina explicitamente o agrupamento no nível de banco de dados. Como cada banco de dados possui seu próprio agrupamento, o agrupamento no nível de servidor é referenciado somente quando o banco de dados é criado primeiro.
No SQL Server 2000, você pode alterar o agrupamento padrão do servidor sem executar novamente a instalação. Basta usar o utilitário Rebuild Master (RebuildM.exe), localizado no diretório Arquivos de Programas\Microsoft SQL Server\80\Tools\BINN. Para obter mais informações, consulte Como recriar o banco de dados mestre (utilitário Rebuild Master) nos Manuais Online do SQL Server 2005 para o SQL Server 2000. O SQL Server 2005 não tem suporte para esse utilitário; use a opção REBUILDDATABASE no Setup.exe em seu lugar. Entretanto, como o agrupamento de servidor não é usado com freqüência, em vez de alterar o agrupamento padrão de uma instância do SQL Server 2005, você pode especificar um agrupamento padrão para cada novo banco de dados que criar.
Se você precisar alterar o agrupamento padrão para uma instância do SQL Server 2005, deve primeiro gravar ou fazer backup no banco de dados, descartar todos os bancos de dados de usuários e depois recriar o banco de dados mestre, especificando o novo agrupamento na propriedade SQLCOLLATION do comando de instalação, da seguinte forma:
start /wait setup.exe /qb INSTANCENAME=MSSQLSERVER REINSTALL=SQL_Engine REBUILDDATABASE=1 SAPWD=test SQLCOLLATION=SQL_Latin1_General_CP1_CI_AI
Agrupamentos no nível de banco de dados
Quando um banco de dados é criado, a cláusula COLLATE da instrução CREATE DATABASE pode ser usada para especificar o agrupamento padrão do banco de dados. Se nenhum agrupamento for especificado durante a criação do banco de dados, o banco de dados será atribuído ao agrupamento padrão do banco de dados de modelo. O agrupamento padrão referente ao banco de dados de modelo é o mesmo do agrupamento padrão da instância do SQL Server.
Cada banco de dados pode ter um agrupamento exclusivo, com a ordem de classificação sendo definida no nível de banco de dados. A Figura 6 mostra como o agrupamento é definido com o uso do SQL Server Management Studio.
Figura 6. Definindo o agrupamento de banco de dados usando a guia Opções da janela Propriedades do Banco de Dados
Você também pode definir a ordem do agrupamento usando Transact-SQL. Por exemplo, para criar um novo banco de dados que usa a ordem de classificação Czech e faz diferenciação de maiúsculas/minúsculas e de caracteres com/sem acento, use uma instrução como esta:
USE master GO CREATE DATABASE Products ON ( NAME = products_dat, FILENAME = 'c:\program files\microsoft sql server\mssql\data\products.mdf' ) COLLATE Czech_CS_AS GO
No SQL Server 2005, você também pode alterar o agrupamento de um banco de dados existente usando o SQL Server Management Studio. No SQL Server 2000, essa funcionalidade não estava disponível no SQL Server Enterprise Manager. Em vez disso, era necessário usar a instrução ALTER DATABASE. Por exemplo, a instrução a seguir altera o agrupamento do banco de dados Products de Czech_CS_AS para Czech_CI_AI (de com para sem diferenciação de maiúsculas/minúsculas e de caracteres com/sem acento):
ALTER DATABASE Products COLLATE Czech_CI_AI
Considerações antes de alterar o agrupamento de um banco de dados
Se você tiver dados em um campo text, varchar ou char e não houver nenhum agrupamento explícito na coluna, a alteração no agrupamento do banco de dados irá alterar a forma como a codificação dos dados é interpretada, resultando em uma forma de corrupção de qualquer caractere fora do intervalo ASCII.
Portanto, evite alterar o agrupamento de qualquer banco de dado que contenha dados de texto não-Unicode, a menos que os dados sejam armazenados em colunas que tenham seu próprio conjunto de agrupamentos explícito.
Para alterar o agrupamento de um banco de dados, as seguintes condições devem ser verdadeiras:
| • | Ninguém pode estar usando o banco de dados. | ||||||||
| • | Nenhum objeto ligado por esquema pode ser dependente do agrupamento de banco de dados. Objetos ligados por esquema são:
| ||||||||
| • | A alteração do agrupamento do banco de dados não cria duplicatas entre nenhum dos nomes de sistema. Se forem encontradas duplicatas, um erro será apontado e ocorrerá falha na ação de alterar o agrupamento. |
Os objetos que podem vir a causar tais duplicações são:
| • | Nomes de objetos (como procedimento, tabela, disparador ou modo de exibição). |
| • | Nomes de esquemas (como grupo, função ou usuário). |
| • | Nomes de tipos escalares (como tipos definidos pelo usuário e do sistema). |
| • | Nomes de catálogos de texto completo. |
| • | Nomes de parâmetros ou colunas em um objeto. |
| • | Nomes de índices em uma tabela. |
Por exemplo, suponha que o seu banco de dados contém duas tabelas chamadas Table1 e TABLE1 e que você tente alterar o agrupamento de French_CS_AS (com diferenciação de maiúsculas/minúsculas e de caracteres com/sem acento) para French_CI_AS (sem diferenciação de maiúsculas/minúsculas e de caracteres com/sem acento). Com o primeiro agrupamento, é possível ter duas tabelas. Entretanto, a alteração no segundo agrupamento gera duplicatas.
Agrupamentos especificados no nível de coluna
No SQL Server 2005, é possível especificar o agrupamento de texto em uma determinada coluna. Isso pode ser muito útil, por exemplo, se você precisar impor a diferenciação de maiúsculas/minúsculas para uma coluna de senhas. Outros cenários onde os agrupamentos no nível de coluna podem ser úteis envolvem vários idiomas na mesma tabela. Por exemplo, a coluna de nomes de clientes pode precisar usar Unicode com o agrupamento Latin1_General para habilitar a classificação apropriada para diversos nomes, enquanto a coluna de linhas de produto pode sempre conter Grego e, para essa coluna, um agrupamento Greek pode fazer sentido. A Figura 7 mostra como escolher um agrupamento e definir as opções da ordem de classificação durante o design da tabela.
Figura 7. Especificando um agrupamento
Se você não tiver definido anteriormente um agrupamento na coluna, quando clicar na coluna, a caixa de diálogo listará o <banco de dados padrão< referente à propriedade Collation da coluna. Para alterar o agrupamento, clique no botão de reticências (...). Isso abre a caixa de diálogo Agrupamento, na qual você seleciona um agrupamento do Windows ou do SQL Server e define as opções de classificação.
Quando você seleciona um agrupamento do Windows, pode especificar se deseja que o agrupamento faça diferenciação de maiúsculas/minúsculas, de largura de caracteres, de caracteres com/sem acento e de caracteres tipo kana.
Também pode definir agrupamentos no nível de coluna com o uso de Transact-SQL adicionando uma cláusula COLLATE à definição de colunas na instrução CREATE TABLE.
O exemplo a seguir mostra como usar o Transact-SQL para especificar um agrupamento para a coluna de cargos que está definida como arábico e sem diferenciação de maiúsculas/minúsculas, de caracteres com/sem acento e de caracteres tipo kana.
CREATE TABLE jobs
(
job_id smallint
IDENTITY(1,1)
PRIMARY KEY CLUSTERED,
job_desc varchar(50)
COLLATE Arabic_CI_AI_KS
NOT NULL
DEFAULT 'New Position - title not formalized yet',
)
Você também pode usar a instrução ALTER TABLE para alterar o agrupamento no nível de coluna (exceto para uma coluna ntext ou text). Se a cláusula COLLATE não for especificada, a alteração no tipo de dados de uma coluna fará com que o agrupamento da coluna seja alterado para o agrupamento padrão do banco de dados.
No SQL Server 2005, você também pode alterar o agrupamento via programação usando a propriedade column.collation no SQL Management Objects (SMO).
A cláusula COLLATE pode ser usada para alterar os agrupamentos de colunas somente dos tipos de dados char, varchar, nchar e nvarchar. Para alterar o agrupamento de uma coluna de tipos de dados de alias definidos pelo usuário, execute instruções ALTER TABLE separadas para alterar a coluna para um tipo de dados de sistema do SQL Server, altere o agrupamento e retorne a coluna para um tipo de dados de alias.
ALTER COLUMN não poderá ter uma alteração de agrupamento se uma ou mais das seguintes condições existirem:
| • | Se uma restrição CHECK ou FOREIGN KEY ou uma coluna computada fizer referência à coluna que está sendo alterada. |
| • | Se algum índice, estatística ou índice de texto completo for criado na coluna. As estatísticas criadas automaticamente na coluna alterada serão descartadas caso o agrupamento da coluna seja alterado. |
| • | Se uma função ou modo de exibição ligado por esquema fizer referência à coluna. |
Você pode inserir ou atualizar valores em uma coluna de texto cujo agrupamento seja diferente da página de código do agrupamento padrão do banco de dados. O SQL Server converte implicitamente os valores para a o agrupamento da coluna.
Agrupamentos especificados em expressões
Os agrupamentos no nível de expressão são definidos na hora em que uma instrução é executada e afetam a forma como um conjunto de resultados é retornado. Isso permite classificar resultados para que a cláusula ORDER BY possa ser específica do idioma.
Durante a instalação do SQL Server, você deverá selecionar agrupamentos binários ou agrupamentos do Windows. Sua escolha de agrupamentos afeta o comportamento da ordem de classificação e comparação de dados da sua instância do Microsoft SQL Server.
Talvez haja muitas instâncias quando você precisar exibir dados para pessoas em diferentes países e quiser a classificação apropriada de localidade. Tanto no SQL Server 2000 como no 2005, é possível especificar agrupamentos em expressões. Esse recurso eficiente permite classificar de maneira que a cláusula ORDER BY possa ser específica do idioma.
Por exemplo, a consulta a seguir no banco de dados AdventureWorks classifica a tabela Person.Address pela cidade do endereço. A ordem de classificação Lithuanian é um bom exemplo das diferenças de agrupamento porque as regras sobre a forma como a letra Y é classificada são surpreendentes.
SELECT * FROM Person.Address ORDER BY City COLLATE Lithuanian_CI_AI
O exemplo a seguir supõe que Table1 não tem nenhum agrupamento explícito no nível de coluna. Nesse caso, as duas colunas são comparadas com o uso da ordem de classificação Turkish.
SELECT * FROM Table1 WHERE Field1 = Field2 COLLATE Turkish_ci_ai
Para obter uma explicação de como os agrupamentos são usados em comparações, consulte a seção "Regras de precedência para agrupamentos", mais adiante neste artigo.
Palavra-chave COLLATE
Um agrupamento pode ser definido no nível de banco de dados, de coluna ou em uma expressão. Para especificar o agrupamento referente a um banco de dados, coluna ou expressão de caracteres, use a seguinte sintaxe:
COLLATE [<Windows_Collation_name>|<SQL_Collation_Name>]
Se a coluna não for definida com o uso de um tipo de dados Unicode (ntext, nvarchar, nvarchar(max), nchar), o agrupamento será convertido em uma página de código.
A palavra-chave COLLATE oferece a opção de usar estes dois tipos de agrupamentos:
Agrupamentos do Windows
São definidos pelo Windows. Você pode alterar as opções para especificar diferenciação de maiúsculas/minúsculas, de largura de caracteres, de caracteres com/sem acento e de caracteres tipo kana e pode escolher uma ordem de classificação binária.
Agrupamentos do SQL
São fornecidos para compatibilidade com versões anteriores. Não é possível configurar a ordem de classificação.
Em geral, tente usar os agrupamentos do Windows sempre que puder. O exemplo a seguir apresenta uma lista de nomes e códigos de países, mostrando como o comportamento de classificação pode mudar, dependendo do agrupamento. A parte superior da Janela de Consulta mostra a lista classificada pelos agrupamentos padrão; a parte inferior mostra os mesmos dados classificados pelo agrupamento Lithuanian.
No agrupamento padrão, mostrado primeiro, Y vem entre X e Z. No agrupamento Lithuanian, mostrado em segundo lugar, Y vem entre I e J.
Figura 8. Efeito do agrupamento Lithuanian na classificação
Regras de precedência para agrupamentos
Como é possível especificar agrupamentos no nível de servidor, de banco de dados, de colunas e em expressões, é importante entender como os agrupamentos interagem. A precedência de agrupamento determina como as expressões que são avaliadas como uma cadeia de caracteres são agrupadas e determinam o agrupamento usado por operadores que usam entradas de cadeias de caracteres, mas não retornam uma cadeia de caracteres, como LIKE e IN.
As regras de precedência de agrupamento no SQL Server 2005 aplicam-se somente aos tipos de dados de cadeia de caracteres: char, varchar, text, nchar, nvarchar e ntext. Objetos que tenham outros tipos de dados não participam de avaliações de agrupamentos.
Os operadores de comparação e os operadores MAX, MIN, BETWEEN, LIKE e IN fazem diferenciação de agrupamentos. A cadeia de caracteres usada pelos operadores é atribuída ao rótulo de agrupamento do operando que tem maior precedência. O operador UNION também faz diferenciação de agrupamentos. Todos os operandos de cadeia de caracteres e o resultado final são atribuídos ao agrupamento do operando com precedência máxima. A precedência de agrupamento dos operandos UNION e o resultado são avaliados coluna por coluna.
O operador de atribuição não faz diferenciação de agrupamentos, e a expressão direita é convertida para o agrupamento esquerdo.
O operador de concatenação da cadeia de caracteres não faz diferenciação de agrupamentos. Os dois operandos de cadeia de caracteres e o resultado são atribuídos ao rótulo de agrupamento do operando que tem precedência de agrupamento máxima. Os operadores UNION ALL e CASE também não fazem diferenciação de agrupamentos. Todos os operandos de cadeia de caracteres e os resultados finais são atribuídos ao rótulo de agrupamento do operando com precedência máxima. A precedência de agrupamento dos operandos UNION ALL e o resultado são avaliados coluna por coluna.
Como os objetos têm diferentes agrupamentos em vários níveis, o SQL Server 2005 apresenta rótulos de agrupamento para ajudá-lo a gerenciar a complexa interação de agrupamentos. Um rótulo de agrupamento nomeia uma categoria de objetos que podem adotar um agrupamento. As regras de agrupamento são descritas em termos de interações entre rótulos de agrupamento.
Se uma expressão fizer referência apenas a um objeto de cadeia de caracteres, o rótulo de agrupamento do objeto referenciado será usado. Se a expressão fizer referência a duas expressões de operando que tenham o mesmo rótulo de agrupamento, ele se tornará o rótulo de agrupamento da expressão do operando.
Se uma expressão complexa fizer referência a duas expressões de operando com diferentes agrupamentos, o rótulo de agrupamento do resultado final usará uma série de regras para determinar a precedência dos agrupamentos. Para obter mais informações, consulte Precedência de agrupamento (Transact-SQL) nos Manuais Online do SQL Server 2005.
A lista a seguir descreve os diferentes tipos de rótulos de agrupamento. Em seguida, vem um gráfico que resume as possíveis interações dos rótulos de agrupamento.
Explícita
Um agrupamento é explicitamente definido para uma determinada expressão ou explicitamente convertido para um agrupamento (X) específico com o uso de uma cláusula COLLATE na expressão.
Implícita
Uma coluna é referenciada. Mesmo se a coluna for explicitamente atribuída a um agrupamento com o uso de uma cláusula COLLATE na instrução CREATE TABLE ou CREATE VIEW, uma referência de coluna será classificada como implícita.
Padrão coercitivo
O agrupamento no nível de banco de dados é usado para qualquer variável de cadeia de caracteres, parâmetro ou literal Transact-SQL, a saída de uma função interna de catálogo ou a saída de uma função interna que não adota entradas de cadeia de caracteres mas produz uma saída de cadeia de caracteres.
Se o objeto for declarado em uma função definida pelo usuário, um procedimento armazenado ou um disparador, ele será atribuído ao agrupamento padrão do banco de dados no qual a função, o procedimento armazenado ou o disparador é criado. Se o objeto for declarado em um lote, ele será atribuído ao agrupamento padrão do banco de dados atual da conexão.
Nenhum agrupamento
Quando o valor de uma expressão for o resultado de uma operação entre duas cadeias de caracteres que possuem agrupamentos conflitantes do rótulo de agrupamento implícito, o resultado da expressão será definido como não tendo um agrupamento.
Por exemplo, considere a seguinte instrução Transact-SQL para criar uma tabela:
CREATE TABLE TestTab ( id int, GreekCol nvarchar(10) COLLATE greek_ci_as, LatinCol nvarchar(10) COLLATE latin1_general_cs_as ) INSERT TestTab VALUES (1, N'A', N'a') GO
Essa instrução cria uma tabela com uma coluna que usa um agrupamento Greek sem diferenciação de maiúsculas/minúsculas mas com diferenciação de caracteres com/sem acento, além de uma segunda coluna que usa um agrupamento Latin1 Geral com diferenciação de maiúsculas/minúsculas e de caracteres com/sem acento.
Você poderia tentar usar uma consulta para compará-las explicitamente:
SELECT * FROM TestTab WHERE GreekCol = LatinCol
Entretanto, a consulta retorna um erro:
Msg 468, Level 16, State 9, Line 1 Cannot resolve the collation conflict between "Latin1_General_CS_AS" and "Greek_CI_AS" in the equal to operation.
O erro ocorre porque o servidor não pode comparar dois segmentos de texto que tenham agrupamentos diferentes. No entanto, se você usar a palavra-chave COLLATE para criar explicitamente uma expressão que lhes permita serem compatíveis, como mostra o exemplo a seguir, a consulta funcionará:
SELECT * FROM TestTab WHERE GreekCol = LatinCol COLLATE greek_ci_as
Embora LatinCol geralmente tenha um agrupamento com diferenciação de maiúsculas/minúsculas, o agrupamento da expressão sem essa diferenciação substitui essa propriedade e permite que a letra maiúscula e minúscula 'A' seja tratada de modo igual.
O tipo de dados das entradas é que definirá se uma função fará ou não diferenciação de agrupamentos. As funções CAST, CONVERT e COLLATE fazem diferenciação de agrupamentos para os tipos de dados char, varchar e text. Se a entrada e saída das funções CAST e CONVERT forem cadeias de caracteres, a cadeia de saída terá o rótulo de agrupamento da cadeia de entrada. Se a entrada não for uma cadeia de caracteres, a cadeia de saída será Padrão coercitivo. Nesse caso, será atribuído o agrupamento do banco de dados atual para a conexão ou o banco de dados que contém a função definida pelo usuário, o procedimento armazenado ou o disparador no qual CAST ou CONVERT é referenciado.
Para funções internas que retornam uma cadeia de caracteres que não adota uma entrada de cadeia, a cadeia de caracteres do resultado será Padrão coercitivo e receberá o agrupamento do banco de dados atual ou do banco de dados que contém a função definida pelo usuário, o procedimento armazenado ou o disparador no qual a função é referenciada.
Limitações da palavra-chave COLLATE
A palavra-chave COLLATE e seus recursos relacionados são eficazes e oferecem uma grande flexibilidade ao desenvolvedor de banco de dados internacional. Entretanto, existem algumas limitações. Esta seção lista essas limitações e suas respectivas soluções alternativas.
Retornando menos que a lista completa de agrupamentos
A função fn_helpcollations retorna uma lista de todos os agrupamentos fornecidos pelo SQL Server. A exceção são três agrupamentos que são preteridos e não aparecem em ::fn_helpcollations(). O agrupamento Hindi é preterido no SQL Server 2005 porque esta versão do SQL Server usa a tabela de classificação Windows 2000 Beta 2. O agrupamento ainda existe no servidor, mas não terá suporte em uma futura versão do SQL Server. Os agrupamentos Hindi e Lithuanian_Classic são preteridos no SQL Server 2005. Eles ainda existem no servidor, mas não terão suporte em uma futura versão do SQL Server.
Se deseja trabalhar via programação com os agrupamentos, você mesmo deve fornecer uma interface do usuário para essa funcionalidade.
Conversão implícita
A conversão implícita de dados de caracteres não-Unicode entre agrupamentos é determinística. Mas também pode ser considerada não-determinística, a menos que o nível de compatibilidade seja definido como 80 ou anterior.
Nas versões anteriores do SQL Server, os nomes de tipos e objetos do sistema foram comparados com o agrupamento do banco de dados mestre. No SQL Server 2005, esses nomes são automaticamente convertidos para corresponder ao agrupamento do banco de dados atual. Se as referências a esses objetos no script ou nos aplicativos não corresponderem à forma como eles aparecem no catálogo e o agrupamento do banco atual provocar uma incompatibilidade, poderá ocorrer falha no script ou no aplicativo. Por exemplo, a instrução EXEC SP_heLP falhará se o banco de dados atual tiver um agrupamento com diferenciação de maiúsculas/minúsculas.
Problemas com a definição de agrupamentos no nível de coluna
De vez em quando, pode haver um banco de dados que requeira uma ordem de classificação (por exemplo, Latin1_General) e colunas individuais que requeiram outra ordem (por exemplo, Greek). Também pode acontecer de o banco de dados conter dados multilíngües que precisem ser classificados de acordo com mais de um agrupamento, por isso não é possível definir um único agrupamento. Nos dois casos, a capacidade de definir vários agrupamentos, que podem ser indexados separadamente, significa que você pode acessar os dados de cada idioma de destino especificando o agrupamento correto. Por exemplo, você pode facilmente exibir dados de Greek especificando o agrupamento Greek.
Além disso, a especificação do agrupamento adicional permite usar pesquisa indexada em consultas nesses dados. A capacidade de indexar a coluna para pesquisa é um requisito fundamental. No exemplo do parágrafo anterior, o uso de uma expressão COLLATE na cláusula ORDER BY de uma consulta fornece a funcionalidade necessária para classificar os dados. Entretanto, a ordenação não será indexada, pois os resultados da consulta serão retornados mais lentamente em conjuntos de dados maiores. Por esse motivo, o agrupamento no nível de coluna faz sentido somente se você não tiver dados monolíngües em uma coluna ou se você desnormalizar seu banco de dados para armazenar idiomas diferentes em colunas diferentes.
Agrupamentos e tempdb
O banco de dados tempdb é criado toda vez que o SQL Server é iniciado. tempdb sempre tem o mesmo agrupamento padrão que o banco de dados model. Esse agrupamento geralmente é o agrupamento padrão da instância. Se você criar um banco de dados de usuário e especificar um agrupamento padrão diferente de model, o banco de dados de usuário terá um agrupamento padrão diferente de tempdb. Todas as tabelas temporárias ou procedimentos armazenados temporários são criados e armazenados em tempdb. Isso significa que todas as colunas implícitas em tabelas temporárias e todas as constantes, variáveis e parâmetros de Padrão coercitivo em procedimentos armazenados temporários possuem agrupamentos que são diferentes dos objetos comparáveis criados em procedimentos armazenados ou tabelas permanentes.
Isso pode levar a problemas de incompatibilidade em agrupamentos entre objetos de banco de dados do sistema e de bancos de dados definidos pelo usuário. Por exemplo, suponha que uma instância do SQL Server 2005 usa o agrupamento Latin1_General_CS_AS e você executa as seguintes instruções:
CREATE DATABASE TestDB COLLATE Estonian_CS_AS; USE TestDB; CREATE TABLE TestPermTable (PrimaryKey int PRIMARY KEY, Col1 nchar ); INSERT TestPermTable VALUES (1, 'a')
Em seguida, crie uma tabela temporária com as mesmas declarações de coluna que TestPermTab, usando estas instruções:
CREATE TABLE #TestTempTable (PrimaryKey int PRIMARY KEY, Col1 nchar ) INSERT #TestTempTable SELECT * FROM TestPermTable GO
Neste sistema, o banco de dados tempdb usa o agrupamento SQL_Latin1_General_CP1_CI_AS (página de código 1252), ao passo que TestDB e TestPermTable.Col1 usam o agrupamento Estonian_CS_AS (página de código 1257).
Em seguida, você consulta as linhas que devem ser as mesmas, usando estas instruções:
SELECT * FROM TestPermTable t1 JOIN #TestTempTable t2 ON t1.Col1 = t2.Col1
Como tempdb usa o agrupamento de servidor padrão e TestPermTable.Col1 usa outro agrupamento, o SQL Server retorna este erro:
"Msg 468, Level 16, State 9, Line 1 Cannot resolve the collation conflict between "SQL_Latin1_General_CP1_CI_AS" and "Estonian_CS_AS" in the equal to operation."
Para impedir o erro, você pode usar uma das seguintes alternativas:
| • | Especificar que a coluna de tabela temporária usa o agrupamento padrão do banco de dados de usuário, e não tempdb. Isso permite que a tabela temporária funcione com tabelas formatadas de modo semelhante em vários bancos de dados, se isso for exigido do sistema. |
| • | Especificar explicitamente o agrupamento correto para a coluna #TestTempTable. Você pode fazer isso usando a palavra-chave COLLATE na definição de colunas. |
LCIDs e agrupamentos
O Windows usa a identificação de localidade (LCID) para definir ordens de classificação. Se você não souber o LCID, poderá usar o LCID padrão especificando 1024 ou formatar os dados usando as funções de formatação do Microsoft .NET. Em um aplicativo ASP baseado na Web, você pode usar a função SetLocale no Microsoft Visual Basic Scripting Edition (VBScript) para alterar a formatação a fim de usar as preferências de data/hora, número e moeda de cada localidade. Entretanto, como não há um mapeamento direto entre o LCID e os agrupamentos, não é possível determinar o agrupamento correto de um LCID.
Isso é inconveniente se você quiser que a melhor ordem de classificação seja atribuída automaticamente para usuários, com base em suas identificações de localidade. Por exemplo, se você tiver um site multilíngüe, com pessoas de diferentes países visitando e exibindo informações de produto, poderá mapear as variáveis HTTP_ACCEPT_LANGUAGE fornecidas pelos navegadores delas aos LCIDs para formatar valores de data e moeda usando a propriedade Session.LCID. Em prol da usabilidade, talvez seja recomendável implementar a classificação usando a localidade delas.
Para ajudar a criar sua própria função de mapeamento para contornar essa questão, você pode usar a lista de designadores de agrupamento fornecida na instalação. Um designador de agrupamento fornece um mapeamento entre um agrupamento específico e um padrão. Para obter uma lista de localidades do sistema e os agrupamentos padrão recomendados, consulte Configurações de agrupamentos na instalação nos Manuais Online do SQL Server 2005.
Veja a seguir alguns exemplos de agrupamentos padrão usados para mapeamento:
| • | Latin1_General pode ser usado para o conjunto de caracteres do inglês norte-americano (página de código 1252). |
| • | Modern_Spanish pode ser usado para todas as variações de espanhol que usam o mesmo conjunto de caracteres do inglês norte-americano (página de código 1252). |
| • | Arabic pode ser usado para todas as variações de arábico que usam o mesmo conjunto de caracteres do arábico (página de código 1256). |
| • | Japanese_Unicode pode ser usado para a versão Unicode de japonês, que tem uma ordem de classificação diferente do japonês mas a mesma página de código (932). |
Também é possível especificar a ordem de classificação a ser usada com o designador de agrupamento que você selecionou. Binária é a ordem de classificação mais rápida e faz diferenciação de maiúsculas/minúsculas. Se uma ordem de classificação binária for selecionada, você não poderá usar as opções para diferenciação de maiúsculas/minúsculas, de largura de caracteres, de caracteres com/sem acento e de caracteres tipo kana.
Cadeias de caracteres ISO e agrupamentos
No VBScript, você pode obter a variável HTTP_ACCEPT_LANGUAGE com um script com este:
Dim stLang
stLang = Request.ServerVariables("HTTP_ACCEPT_LANGUAGE")
Como muitos desenvolvedores da Web usam esse valor para informações de localidade, a função SetLocale no VBScript foi desenvolvida para aceitar esse valor diretamente, além de valores LCID. Isso significa que você não precisa passar para a etapa intermediária de mapeamento do valor referente a um LCID. Para cada cadeia de caracteres que representa uma localidade, como "en-us" (inglês norte-americano) ou "vi" (vietnamita), é necessário mapear para o agrupamento apropriado, como Latin1_General ou um agrupamento vietnamita.
Agrupamentos personalizados
É comum os desenvolvedores quererem definir seus próprios agrupamentos. Entretanto, como todos os novos agrupamentos do SQL Server derivam de agrupamentos do Windows, não é possível criar novos agrupamentos.
Um agrupamento deve ser projetado para definir o método de classificar todo caractere definido no padrão Unicode e, além disso, não há nenhuma interface de usuário para criar novos agrupamentos.
Agrupamento e caracteres suplementares
Os caracteres suplementares só podem ser usados em operações de ordenação e comparação se você usar um dos agrupamentos _90. Essas comparações se baseiam apenas em pontos de código, e não em outros meios lingüisticamente significativos. Cuidado ao usar caracteres suplementares em operações como ORDER BY, GROUP BY e DISTINCT, principalmente quando houver caracteres suplementares e não-suplementares incluídos na mesma operação.
Como os caracteres suplementares são armazenados em pares de dois caracteres Unicode de dois bytes, a função LEN() retorna o valor 2 para cada caractere suplementar que estiver contido na cadeia de argumentos. Da mesma forma, as funções CHARINDEX e PATINDEX representam incorretamente a ocorrência de caracteres suplementares em cadeias de caracteres, e a função NCHAR retorna um caractere que representa somente uma metade do par de caracteres suplementares. A conversão de um valor binary ou varbinary em um caractere suplementar produz somente uma metade do par de caracteres suplementares.
As funções LEFT, RIGHT, SUBSTRING, STUFF e REVERSE podem dividir qualquer par de caracteres suplementares e levar a resultados inesperados.
No SQL Server 2005, é possível ignorar as limitações das funções de sistema do SQL Server ao trabalhar com caracteres suplementares usando funções CLR definidas pelo usuário. Para obter mais informações sobre como criar e usar funções que reconheçam caracteres suplementares usando código gerenciado no Common Language Runtime do .NET Framework, consulte os exemplos fornecidos com o SQL Server 2005. O exemplo StringManipulate demonstra o processamento de cadeias que reconhecem caracteres suplementares e a implementação das funções de cadeia de caracteres LEN(), LEFT(), RIGHT(), SUBSTRING() e REPLACE(), mas com a capacidade adicional de reconhecimento de caracteres suplementares para manipular cadeias de caracteres suplementares e Unicode. O exemplo inclui scripts no C# ou no Visual Basic NET, além de um script Transact-SQL para carregar o assembly e criar as funções no SQL Server. Para obter mais informações sobre os exemplos disponíveis, consulte Criando funções CLR nos Manuais Online do SQL Server 2005.
Comunicação servidor-cliente (Tecnologias de acesso a dados)
Em aplicativos de banco de dados, não é suficiente usar apenas as ferramentas do SQL Server, tal como o SQL Server Management Studio. Geralmente, o servidor interage com outros servidores ou clientes, usando um ou mais padrões de acesso a dados. Neste contexto, o aplicativo ou camada que se conecta ao SQL Server é chamado de cliente. Para a finalidade desta discussão, existem dois tipos de clientes:
| • | Clientes Unicode — SQL Native Client, OLE DB e ODBC versões 3.7 e posteriores (MDAC 2.8 e posterior) |
| • | Clientes não-Unicode — ODBC versão 3.7 e anterior, e biblioteca do banco de dados (MDAC 2.xx) |
Esta seção apresenta as tecnologias de acesso a dados que estão disponíveis e discute resumidamente os problemas que você pode encontrar ao trabalhar com dados multilíngües em um ambiente de cliente-servidor.
Biblioteca do banco de dados
Embora o Mecanismo de Banco de dados do SQL Server 2005 ainda ofereça suporte a conexões a partir de aplicativos existentes através da biblioteca do banco de dados e das APIs SQL incorporadas, ele não inclui os arquivos ou a documentação necessária para fazer o trabalho de programação nos aplicativos que usam essas APIs. Uma futura versão do Mecanismo de Banco de Dados do SQL Server não oferece suporte a conexões a partir da biblioteca do banco de dados ou de aplicativos SQL incorporados. Além disso, não há versão Unicode da biblioteca do banco de dados.
Portanto, não use a biblioteca do banco de dados para desenvolver novos aplicativos. Além disso, remova quaisquer dependências da biblioteca do banco de dados ao modificar os aplicativos existentes. Em vez dessas APIs, use o namespace SQLClient ou uma API como OLE DB ou ODBC.
O SQL Server 2005 não inclui a DLL da biblioteca do banco de dados necessária para executar esses aplicativos. Para executar a biblioteca do banco de dados ou aplicativos SQL incorporados, você precisa ter disponível a DLL da biblioteca do banco de dados do SQL Server versão 6.5, SQL Server 7.0 ou SQL Server 2000.
SQL-DMO
O SQL-DMO (SQL Distributed Management Objects) é uma camada COM que encapsula o banco de dados do SQL Server e o gerenciamento da replicação. Como ele é COM, as mesmas regras que se aplicavam ao ADO e ao OLE DB se aplicam ao SQL-DMO. O SQL-DMO também possui propriedades que podem ser usadas nos recursos mencionados anteriormente, tais como a propriedade Collation no SQLServer2, Database2, Column2, SystemDateType2 e os objetos UserDefinedDataType2.
OLE DB
O OLE DB é o componente central do MDAC (Microsoft Data-Access Components). O OLE DB é baseado em COM e, portanto, todas as seqüências de caracteres são Unicode BSTRs (UTF-16 no Windows XP, Windows Server 2003 e Windows 2000; UCS-2 em todos os outros sistemas operacionais). Entretanto, as versões do MDAC anteriores à MDAC 2.8 SP1 não aceitam instâncias nomeadas. Os aplicativos podem não conseguir se conectar a instâncias nomeadas do SQL Server 2005. Para tirar vantagem dos recursos do SQL Server 2005, atualize para o MDAC 2.8 SP1.
| Versão | Biblioteca de acesso a dados |
SQL Server 7.0 | MDAC versão 2.1 |
SQL Server 2000 | MDAC versão 2.6 |
SQL Server 2005 | MDAC versão 2.8 |
No SQL Server, o provedor é o Microsoft OLE DB Provider for SQL Server (SQLOLEDB). Os dados são convertidos para Unicode, se necessário, através do agrupamento dos dados reais.
ADO
O Microsoft ActiveX Data Objects é uma interface compatível com o Visual Basic e com script que age como um invólucro em torno do OLE DB. Ele também é um componente COM e, portanto, possui o mesmo nível de suporte a Unicode. Não há como separar o ADO e o OLE DB de forma que seja possível permitir conversões entre os dois; portanto, quando houver problemas, eles sempre estarão na camada OLE DB.
ODBC
Algumas versões do ODBC oferecem suporte a Unicode. Uma questão importante dos dados não-Unicode é a forma em que eles são convertidos entre as páginas de código ou a forma como são convertidos em Unicode ou a partir de Unicode quando o ODBC é usado. Quando você usa uma versão do ODBC anterior à 3.7, os dados são convertidos de Unicode para ANSI através da página de código padrão do sistema. Mesmo que você instale uma versão posterior do ODBC, o Jet 3.5 fará a mesma conversão.
Existem duas configurações possíveis do atributo SQL_COPT_SS_TRANSLATE quando enviado para SQLSetConnectAttr:
| • | SQL_XL_OFF O driver não converte caracteres de uma página de código para outra em dados de caracteres trocados entre o cliente e o servidor. |
| • | SQL_XL_ON O driver não converte caracteres de uma página de código para outra em dados de caracteres trocados entre o cliente e o servidor. O driver configura automaticamente a conversão de caracteres, determinando a página de código instalada no servidor e aquela que está sendo usada pelo cliente. |
Por padrão, SQL_XL_ON é o atributo usado. Você também pode defini-lo usando o método TranslateChar do SQL-DMO do objeto SQLServer. Geralmente, esse padrão fornece o comportamento desejado (que é ativar auto_translate) sempre que você estiver lidando com dados não-Unicode.
Se você desativar auto_translate, terá que compreender as conseqüências. Os desenvolvedores geralmente desabilitam a conversão automática presumindo que isso permitirá que o cliente e o servidor se comuniquem sem ter que coincidir as páginas de código. Entretanto, esta interação não tem suporte. Além disso, para realizar classificações e varreduras de dados não-Unicode que foram definidos com um agrupamento do Windows, o SQL Server converte os dados para Unicode antes de realizar a classificação. Portanto, se a conversão automática estiver desabilitada, os dados Unicode convertidos podem não ser reconvertidos corretamente para a sua página de código não-Unicode original quando ela é recuperada no lado do cliente.
Microsoft SQL Native Client
O Microsoft SQL Native Client (anteriormente chamado de SQL Native Client) foi projetado para fornecer um método simplificado de obter acesso dos dados nativos ao SQL Server usando OLE DB ou ODBC. Ele combina as tecnologias OLE DB e ODBC em uma biblioteca, e fornece uma forma de inovar e desenvolver novos recursos de acesso a dados sem alterar os componentes MDAC atuais, que agora fazem parte da plataforma Microsoft Windows.
Se você não precisar usar qualquer um dos novos recursos do SQL Server 2005, não será necessário usar o provedor OLE DB do SQL Native Client; você pode continuar usando o provedor de acesso a dados atual, que geralmente é SQLOLEDB. Se você estiver aprimorando um aplicativo existente e precisar usar os novos recursos do SQL Server 2005, use o provedor OLE DB do SQL Native Client .
O SQL Native Client usa componentes em MDAC, mas não é explicitamente dependente de uma versão particular do MDAC.
Em novos aplicativos, se você estiver usando uma linguagem de programação gerenciada, tal como Microsoft Visual C#.NET ou Visual Basic.NET, e precisar acessar os novos recursos do SQL Server 2005, use o .NET Framework Data Provider for SQL Server, que é parte do .NET Framework for Visual Studio 2005. Isso lhe oferece o componente de acesso a dados mais robusto para trabalhar com o SQL Server 2005.
Se você estiver desenvolvendo um aplicativo baseado em COM e precisar acessar os novos recursos do SQL Server 2005, use o SQL Native Client . O SQL Native Client oferece suporte a bancos de dados anteriores do SQL Server começando com o SQL Server 7.0 e versões mais recentes.
Em aplicativos OLE DB e ODBC, a questão principal é se você precisa ou não acessar os novos recursos do SQL Server 2005. Se você tiver um aplicativo que não precisa dos novos recursos do SQL Server 2005, continue a usar o MDAC. Entretanto, os valores de retorno dos tipos de dados varchar(max), nvarchar(max), varbinary(max), xml, UDT ou outros tipos de objetos grandes não podem ser retornados para as versões do cliente anteriores ao SQL Server 2005. Se você quiser usar esses tipos como valores de retorno, use o SQL Native Client.
O MDAC e o SQL Native Client fornecem acesso a dados nativos para bancos de dados do SQL Server, mas o SQL Native Client foi projetado especificamente para expor os novos recursos do SQL Server 2005, enquanto mantém a compatibilidade com versões anteriores. Além disso, embora o MDAC contenha componentes para uso do OLE DB, ODBC e ActiveX Data Objects (ADO), o SQL Native Client implementa somente o OLE DB e o ODBC.
Para obter mais informações sobre a diferença entre o SQL Native Client e o MDAC, consulte Atualizando um aplicativo para SQL Native Client a partir do MDAC no SQL Server 2005 Books Online.
Para tirar vantagem dos novos recursos introduzidos no SQL Server 2005, os aplicativos existentes que usam o ADO (ActiveX Data Objects) devem usar o provedor OLE DB do SQL Native Client como seu provedor de acesso a dados.
Configurações de servidor e cliente Unicode e não-Unicode
Esta seção apresenta algumas questões a serem consideradas ao trabalhar com sistemas herdados que não são completamente compatíveis com Unicode.
Servidor Unicode e cliente Unicode
Esta é a configuração ideal. Mantendo os dados em Unicode em todo o processo, você pode garantir o melhor desempenho e também proteger os dados recuperados contra corrupção. Este é o caso do ADO e do OLE DB, ou do SQL Server Native Client.
Servidor Unicode e um ou mais clientes não-Unicode
Neste tipo de configuração, você não deve ter quaisquer problemas para armazenar dados, mas existe uma limitação séria quando se trata de trazer os dados para o cliente e usá-los. A página de código do cliente deve ser usada para converter os dados Unicode, em algum momento.
Um exemplo deste cenário é a conexão a um banco de dados do SQL Server 2005 a partir de um computador que esteja usando a biblioteca do banco de dados. A biblioteca do banco de dados é uma interface que permite que aplicativos C acessem o SQL Server. A biblioteca do banco de dados não foi significativamente atualizada desde o SQL Server 6.5. Portanto, ela possui as mesmas limitações que o SQL Server 6.5: Os dados podem ser baseados em somente uma página de código, a página de código OEM do sistema. Você também pode escolher se as informações sobre localidade serão ou não baseadas nas configurações de localidade do sistema cliente. O SQL Server Client Network Utility fornece duas opções não-exclusivas de como a biblioteca do banco de dados converte as informações: conversão automática ANSI para OEM e uso de configurações internacionais. Ambas as opção são selecionadas por padrão.
Como você não pode manipular dados em outras páginas de código, a única vez que a biblioteca do banco de dados deve ser usada na camada de dados é em sistemas herdados que lidam com um subconjunto de dados do SQL Server. Esta tecnologia é fornecida somente para compatibilidade com versões anteriores, mas permanece uma opção se você precisar oferecer suporte a dados multilíngües em aplicativos herdados.
Outros clientes que não são habilitados para Unicode incluem versões anteriores do Microsoft Office Access. Se você conectar a um banco de dados do SQL Server usando uma versão mais antiga do Office Access, o Unicode poderá ser convertido para pontos de interrogação, como mostrado na Figura 9.
Figura 9. Nomes de tabela em japonês, mostrados como pontos de interrogação
Isso acontece porque o comportamento padrão no ODBC 3.7 era converter automaticamente para a página de código do sistema; entretanto, como os caracteres em japonês não eram incluídos na página de código (1252) do computador cliente do inglês (Americano), eles eram substituídos por pontos de interrogação.
Além disso, não é possível conectar a essas tabelas; as tentativas de conexão resultarão em uma mensagem de erro. Jet e ODBC tentam se conectar a uma tabela chamada dbo.????, que falhará porque essa tabela não existe. Este erro ocorrerá com os dados que não estão na página de código do sistema do cliente.
Quando os dados tiverem sido convertidos para a página de código incorreta e substituídos pelos pontos de interrogação, nunca haverá como eles serem reconvertidos. Por exemplo, se você usar um cliente não-Unicode para conectar a uma tabela que contenha dados em coreano em Unicode, os pontos de interrogação substituirão os caracteres de texto em coreano, como mostrado na Figura 10.
Figura 10. Exemplo de caracteres que não podem ser visualizados em um banco de dados não-Unicode do cliente
Todos os três clientes herdados (biblioteca do cliente, ODBC e Jet 3.5) compartilham o mesmo problema de não lidar com Unicode, exceto aqueles caracteres que podem ser convertidos para a página de código padrão do sistema. Evite o uso desses componentes no desenvolvimento do cliente, a não ser que você saiba que os dados podem ser contidos na página de código padrão do sistema. Para obter mais informações, consulte Gerenciando a conversão de dados entre um servidor Unicode Server e um cliente não-Unicode no SQL Server 2005 Books Online.
Além disso, já que COM fornece os pontos de entrada para os dados do SQL Server no Office Access, as configurações regionais do cliente são usadas para interpretar o significado dos dados. Isso pode afetar a entrada dos valores de data/hora, números e valores de moeda. Para obter mais informações sobre o problema, consulte a seção "Lidando com interferência de localidade COM", posteriormente neste documento.
Se você usa o Office Access como um front-end para o SQL Server, recomendamos que você atualize o front-end do Office Access para usar os novos recursos e suporte a Unicode do Microsoft Office 2003 Access ou Microsoft Office System 2007 Access. A Ajuda online do Office Access fornece orientação sobre como atualizar os aplicativos existentes do Office Access. Observe que o formato ADP foi descontinuado após o Microsoft Office Access 2000.
Para obter informações sobre como otimizar o aplicativo Office Access para aprimorar o desempenho e a capacidade de atualização, consulte o white paper Otimizando os aplicativos do Microsoft Office Access vinculados ao SQL Server na biblioteca MSDN.
Servidor não-Unicode e cliente Unicode
Trata-se de uma configuração insuficiente para dados multilíngües, já que você não poderá armazenar os dados no servidor. Como o SQL Server 2000 e o SQL Server 2005 reconhecem Unicode, é improvável que você encontre esta configuração a menos que um servidor vinculado esteja definido como um banco de dados do SQL Server 6.5. Você pode receber dados válidos da instância do SQL Server 6.5, mas não insira quaisquer dados que não estejam incluídos na página de código padrão desse servidor.
Conversão de dados multilíngües de versões anteriores do SQL Server
Alguns aplicativos herdados, que podem ter sido criados antes que o suporte total a Unicode fosse implementado no SQL Server, usam esquemas de codificação personalizados para manipular dados multilíngües. Para preservar os dados, use o programa de cópia em massa (utilitário bcp) para salvar os dados como binários, a fim de evitar erros de conversão. Em seguida, use a cópia em massa para reimportar os dados usando a página de código apropriada através do parâmetro de linha de comando -C. Para obter mais informações sobre o utilitário bcp, consulte a seção Usando utilitários da linha de comando com dados multilíngües deste documento.
Dados multilíngües na interface do usuário
A ferramentas de gerenciamento e administração do SQL Server foram atualizadas a fim de aprimorar o suporte a dados multilíngües. Esta seção descreve algumas das alterações que você verá no SQL Server 2005.
Alterações gerais da interface do usuário
A nova interface do SQL Server Management Studio oferece a flexibilidade para hospedar uma variedade de editores de texto e de consulta, caixas de diálogo de gerenciamento, assistentes, designers e navegador no mesmo shell. Nesse shell, você pode especificar o idioma da sessão e a exibição do controle dos seguintes elementos:
| • | o idioma que será usado em mensagens de erro ou outras mensagens do sistema |
| • | o formato dos dados de data e hora |
| • | os nomes dos dias e meses, incluindo abreviações |
| • | o primeiro dia da semana |
| • | os símbolos e formatos de moeda |
Para alterar a fonte usada no SQL Server Management Studio, no menu Tools, selecione Options, aponte para Environment e, em seguida, selecione Fonts and Colors Page para personalizar o estilo e o tamanho da fonte, assim como as configurações de exibição de cor nas janelas de ferramenta individual que possuem painéis de saída no SQL Server Management Studio. Se você alterar o texto, as alterações não terão efeito durante a sessão em que foram feitas. Entretanto, você pode avaliar os efeitos da alteração, abrindo outra instância do SQL Server Management Studio.
Existem 34 idiomas disponíveis para serem usados como configurações de sessão. Para obter uma lista, consulte sys.syslanguages (Transact-SQL) no SQL Server 2005 Books Online.
Você também pode alterar o texto e as opções de exibição para trabalhar com pacotes do Integration Services ou objetos de mineração de dados e multidimensionais do Analysis Services, usando o Business Intelligence Development Studio. Use as páginas Environment da caixa de diálogo Options para configurar as opções que incluem os idiomas usados no ambiente da interface do usuário e da Ajuda online, as fontes e o esquema de mapeamento de teclado. Depois que você configurar o ambiente de desenvolvimento da forma desejada, suas configurações são salvas em um arquivo *.suo na pasta solution, que você pode reutilizar.
Observação Para exibir caracteres suplementares, você deve instalar uma fonte que ofereça suporte às extensões desses caracteres. Para obter informações, consulte Caracteres substitutos e suplementares na biblioteca MSDN.
Para exibir a lista de idiomas que estão disponíveis na indexação de texto completo e nas operações de consulta, use sys.fulltext_languages. Este modo de exibição de catálogo contém uma linha por idioma. Cada linha fornece uma representação inequívoca dos recursos lingüísticos de texto completo que estão registrados no Microsoft SQL Server. O nome ou LCID pode ser especificado nas consultas de texto completo e na DDL de índice de texto completo.
| • | Para definir o idioma da seção do lado do servidor, use SET LANGUAGE. |
| • | O idioma da sessão também pode ser definido no lado do cliente através de OLE DB, ODBC ou ADO.NET. |
| • | Em OLE DB, use a propriedade SSPROP_INIT_CURRENTLANGUAGE. |
| • | Em ODBC, use a palavra-chave LANGUAGE. Para obter mais informações, consulte SQLConfigDataSource na biblioteca MSDN. |
| • | Em ADO.NET, use o parâmetro Current Language do objeto ConnectionString. |
Suporte a scripts complexos
O SQL Server 2005 oferece suporte à entrada, armazenamento, alteração e exibição de scripts complexos nas ferramentas e no mecanismo do banco de dados. Dentre os scripts complexos se incluem os scripts bidirecionais, tal como o árabe, scripts cujos caracteres mudam de forma dependendo de sua posição, tais como o índico e tailandês, além dos idiomas que requerem dicionários internos para reconhecerem as palavras porque não há quebras entre elas, tais como o tailandês.
Os aplicativos de banco de dados que interagem com o SQL Server devem usar controles que oferecem suporte a scripts complexos. Controles padrão do Windows Forms criados no código gerenciado são habilitados para script complexo. Entretanto, os arquivos necessários para oferecer suporte a scritps complexos precisam ser instalados em seu computador através das configurações regionais e de idioma. Para obter mais informações, consulte Suporte a script complexo no SQL Server 2005 Books Online.
Formatação no criador de consulta
No criador de consulta, na maior parte, você pode inserir informações no Painel de grade que correspondem às configurações regionais padrão do computador, ou pode usar explicitamente a função CONVERT para fazer com que uma seqüência de caracteres em um formato arbitrário seja manipulada.
Existem algumas limitações de design que você deve conhecer quando estiver usando as configurações regionais:
| • | Não há suporte para formatos de dados longos. |
| • | Os símbolos de moeda não devem ser inseridos no Painel de grade, embora o símbolo de dólar norte-americano ($) possa ser usado opcionalmente. De qualquer forma, o símbolo de moeda recuperado das configurações regionais será usado no Painel de resultados. |
| • | Unários negativos sempre aparecem no lado esquerdo sem parênteses, independentemente das configurações regionais. Portanto, -1 deve ser representado como -1 em vez de 1- ou (1) ou qualquer outra variação válida que possa ser especificada na caixa de diálogo Opções Regionais. |
Essas limitações são necessárias para permitir certo nível de suporte mundial no criador de consulta, mas não bloquearão a maior parte dos esforços para usar dados de localidade específica.
Como quaisquer informações inseridas no Painel de grade serão convertidas para um formato independente de localidade no painel SQL, "03.09.65" em um computador alemão padrão será convertido para { ts ' 1965-09-03 00:00:00 }. Todos os dados inseridos diretamente no painel SQL devem estar nesse formato ou incluir uma chamada CONVERT explícita.
Ordem de classificação
A classificação de dados exibida no Painel de resultados não é influenciada pelas Configurações Regionais; em vez disso, as regras de agrupamento controlam como uma cláusula ORDER BY é interpretada.
Transact-SQL multilíngüe
Quando você envia uma declaração SQL que contém dados multilíngües para o servidor, duas questões afetam a transmissão correta dos dados para o servidor: (1) a codificação da própria instrução SQL e (2) a codificação das literais de seqüência dentro da instrução.
Codificando instruções SQL
Existem restrições nos caracteres que podem ser usados em instruções Transact-SQL. Você pode inserir caracteres DBCS em literais, nomes de objeto de banco de dados, aliases, nomes de parâmetro e caracteres de marcador de parâmetro. Entretanto, você não pode usar caracteres DBCS em elementos de idioma SQL, tais como nomes de função ou palavras-chave SQL. Portanto, quando você digita palavras-chave SQL, tal como SELECT, use os caracteres de meia largura "SELECT" em vez dos caracteres de largura total japoneses, "‚r‚d‚k‚d‚b‚s".
Se a seqüência de caracteres SQL usa Unicode (por exemplo, qualquer seqüência de caracteres SQL que usa ADO), você pode codificar qualquer tipo de caractere. Se a seqüência de caracteres não usa Unicode (por exemplo, uma seqüência em um arquivo de lote não-Unicode ou arquivo .sql), a conversão deve ser feita em algum momento. Ao fazer essa conversão, você deve planejar cuidadosamente e levar em consideração a página de código padrão do sistema do computador no qual a conversão é feita para evitar problemas em aplicativos multilíngües.
Codificando literais de seqüência em instruções SQL
As constantes de seqüência de caracteres Unicode que aparecem no código executado no servidor, tal como em procedimentos armazenados e disparadores, devem ser precedidas pela letra maiúscula N. Se uma literal de seqüência não estiver em Unicode (marcada com o prefixo N), a seqüência de caracteres será convertida para a página de código padrão do banco de dados, que talvez não reconheça determinados caracteres. Com dados multilíngües é melhor usar um tipo de dados Unicode e literais de seqüência Unicode.
O exemplo seguinte mostra uma seqüência de caracteres Unicode designada pela colocação de um prefixo "n" na frente dela:
SELECT n'??????'
A Figura 11 mostra como esta seqüência de caracteres, que é o nome em híndi do idioma híndi, apareceria em um computador que tivesse a fonte híndi correta instalada.
Figura 11. Exemplo de caracteres em híndi no cliente híndi
Se o prefixo "n" não fosse colocado antes da seqüência de caracteres, ela seria convertida para ??????. Isso também acontece com os dados que têm uma página de código que não corresponde aos padrões do sistema.
Aviso Lembre-se de usar o prefixo "n" em literais de seqüência e em tipos de dados (nchar, nvarchar e ntext) para representar que os dados Unicode são específicos do SQL Server. A especificação ANSI-92 SQL define os tipos de dados de caractere National, mas não especifica que eles têm que ser Unicode. A especificação ANSI-99 SQL discute o uso de um conjunto de tipos Unicode com um prefixo "u" (por exemplo, utext, uchar e uvarchar). Esses tipos de dados não estão disponíveis no SQL Server.
Use o prefixo N antes das seqüências de caracteres para se certificar de que elas são passadas como Unicode. Isso ajuda a evitar problemas não-intencionados com as conversões durante o uso da página de código padrão do servidor.
Se o seu aplicativo não envia dados Unicode para o SQL Server e a página de código ANSI do cliente corresponde à página de código do SQL Server, não será necessário prefixar as constantes de seqüência de caractere com N. Você não perderá os dados como um resultado da omissão do prefixo.
Se você estiver usando um servidor vinculado com o SQL Server 7.0, existem problemas adicionais a serem considerados. O SQL Server 7.0 permite que você selecione um agrupamento Unicode durante a instalação que seja distinto da ordem de classificação; em alguns casos, isso faz com que as operações que envolvem seqüências de caracteres prefixadas com N produzam resultados diferentes das que não possuem o prefixo. Para obter mais informações sobre essa questão, visite o site Ajuda e Suporte da Microsoft.
Funções de manipulação de seqüências
O Transact-SQL possui funções de manipulação de seqüências de caracteres internas que possuem importantes considerações multilíngües:
ASCII
Retorna o ponto do código do primeiro caractere em uma seqüência de caracteres usando a página de código padrão do sistema atual. Se o caractere não estiver nessa página de código, será retornado 63 (o ponto de código de um ponto de interrogação). Isso é semelhante à função Asc() em Visual Basic e VBScript.
CHAR
Retorna um caractere, dado o ponto de código ANSI. Isso é essencialmente o inverso da operação da função ASCII; é semelhante à função Chr() em Visual Basic e VBScript. Se o ponto de código não estiver no intervalo 0–255, será retornado Null.
NCHAR
Retorna um caractere, dado seu ponto de código Unicode. NCHAR é o Unicode equivalente da função CHAR. Ela é semelhante à função ChrW() em Visual Basic e VBScript.
UNICODE
Retorna o ponto de código Unicode do primeiro caractere em uma seqüência de caracteres. UNICODE é o Unicode equivalente à função ASCII. Ela é semelhante à função Asc() em Visual Basic e VBScript.
Um exemplo da função NCHAR pode ser encontrado anteriormente neste documento (consulte a seção "Tipos de data/hora: datetime, smalldatetime"), onde ela era usada para adicionar a RLM (marca de direita para a esquerda) antes de uma data Hijri. Adicionar a marca RML garante que a data está formatada da maneira esperada.
Suporte à localidade no SQL Server 2005
O SQL Server 2000 incluía suporte à localidade específico para 33 idiomas diferentes. No SQL Server 2005, o suporte era adicionado para todos os idiomas aceitos pelos sistemas operacionais Microsoft Windows. O Apêndice B contém uma lista de todos os idiomas que têm suporte, juntamente com as suas IDs de localidade.
Você pode enumerar esses idiomas e as informações sobre eles usando o procedimento armazenado sp_helplanguage. Observe que embora cada versão do SQL Server vá armazenar informações completas sobre muitos dos itens listados abaixo, você não obterá mensagens traduzidas do sistema para todas as localidades, a menos que tenha instalado uma versão localizada do produto.
As informações sobre os idiomas são armazenadas na tabela syslanguages, exceto para mensagens, que são armazenadas em sysmessages.
Configurações de idioma
Cada instância do SQL Server deve ter um idioma padrão usado para manipular itens tais como os formatos de data e as mensagens. Essas informações são armazenadas em cada logon no servidor que é criado. Embora a definição de um idioma padrão do servidor seja inicialmente feita durante a configuração, ela pode ser substituída no nível do servidor na guia Advanced na caixa de diálogo SQL Server Properties, conforme mostrado na Figura 12. (No SQL Server 2000, essa opção fica na guia Server Settings).
Figura 12. Definindo o idioma padrão do servidor
Você também pode usar o procedimento armazenado sp_configure para alterar o idioma padrão. Por exemplo, a instrução seguinte altera o idioma para italiano:
sp_configure "language", 6
A configuração de idioma padrão pode ser substituída em cada logon, através do procedimento armazenado sp_addlogin ou da caixa de diálogo Login Properties mostrada na Figura 13.
Figura 13. Definindo o idioma padrão de um logon
O idioma padrão pode ser substituído no nível da sessão, através da instrução SET LANGUAGE, conforme mostrado nos exemplos seguintes:
SET LANGUAGE French
SET LANGUAGE èeština
SET LANGUAGE Çѱ¹¾î
SET LANGUAGE N'“ú–{Œê'
Trabalhando com seqüências de caracteres
Os métodos individuais de acesso a dados fornecem seus próprios meios de especificar a definição do idioma fora de uma chamada SET LANGUAGE:
| • | O ADO oferece suporte a uma palavra-chave de idioma específico do provedor em ConnectionString. |
| • | O OLE DB pode definir a propriedade SSPROP_INIT_CURRENTLANGUAGE específica do provedor. |
| • | O ODBC pode especificar um idioma na definição da fonte de dados ou em uma palavra-chave LANGUAGE na seqüência de conexão. |
| • | A biblioteca do banco de dados pode usar dblogin para alocar LOGINREC e, em seguida, DBSETNATLANG para especificar uma definição de idioma. |
As configurações de idioma (se especificadas no nível do servidor, logon ou sessão) afetam estes itens:
| • | Mensagens |
| • | Data/hora |
| • | Primeiro dia da semana |
| • | Moedas e símbolos de moeda |
| • | Nomes de mês/dia e nomes de mês abreviados |
Mensagens
O SQL Server 2000 e o SQL Server 2005 oferecem suporte a várias cópias, de idioma específico, das seqüências de caracteres e mensagens de erro do sistema. Essas mensagens são armazenadas na tabela sysmessages do banco de dados mestre. Quando você instala uma versão localizada do SQL Server, essas mensagens do sistema são traduzidas para essa versão do idioma. Por padrão, você também possui o conjunto Inglês (Americano) dessas mensagens. Use Set Language para especificar o idioma da sessão do servidor. Por padrão, as mensagens são enviadas no idioma da versão instalada.
Quando o SQL Server envia uma mensagem para uma conexão, ele usa a mensagem localizada, se o Conjunto de IDs do idioma corresponder a uma das IDs de idioma da coluna msglangid da tabela sysmessages . Essas IDs são em formato decimal e representam a ID de localidade (LCID) da mensagem. Se não houver mensagem na tabela sysmessages com a mesma LCID, as mensagens em Inglês (Americano) serão enviadas.
Você pode adicionar uma mensagem definida pelo usuário de idioma específico na tabela sysmessages usando o parâmetro @lang do procedimento armazenado do sistema sp_addmessage. O número do erro deve ser maior que 50.000 e você deve especificar o parâmetro @lang como o idioma, ou alias nomeado que mapeia para a LCID, da mensagem. Como várias seqüências de caracteres e mensagens de erro do sistema de idioma específico podem ser instaladas no servidor, o valor de language especifica o idioma no qual as mensagens devem ser gravadas na tabela sysmessages. Quando o idioma é omitido, ele passa a ser o idioma padrão da sessão do servidor. As definições de idioma com suporte são armazenadas em master.dbo.syslanguages.
Se você instalar versões de vários idiomas de sysmessages, visite o site Ajuda e Suporte da Microsoft para conhecer as etapas e os requisitos adicionais. Não há suporte para instalações de versões de idioma diferentes das instâncias do SQL Server no mesmo computador. Por exemplo, o SQL Server 2005 em alemão e o SQL Server 2005 em português (Brasil) não têm suporte como instâncias múltiplas no mesmo computador.
Observação Muitas das tabelas do sistema de versões anteriores do SQL Server são implementadas como um conjunto de modos de exibição no SQL Server 2005. Esses modos de exibição são conhecidos como modos de exibição de compatibilidade, e eles se destinam somente à compatibilidade com versões anteriores. Os modos de exibição de compatibilidade expõem os mesmos metadados que estavam disponíveis no SQL Server 2000. Entretanto, eles não expõem os metadados relacionados aos recursos introduzidos no SQL Server 2005.
Data/hora
Cada idioma possui um padrão apropriado para o formato de data curta: mdy, dmy ou ymd. Você pode substituí-lo no nível da conexão através da definição SET DATEFORMAT. Para recuperar a data curta padrão, use o procedimento armazenado sp_helplanguage. O valor é armazenado na coluna dateformat.
Primeiro dia da semana
O primeiro dia da semana varia entre localidades diferentes; entre os 33 idiomas da tabela syslanguages, ele varia entre 1 (segunda-feira) e 7 (domingo). Essas informações podem ser recuperadas através do procedimento armazenado sp_helplanguage. O valor é armazenado na coluna datefirst.
Moeda e símbolos de moeda
Qualquer coluna do tipo money ou smallmoney pode incluir um símbolo de moeda. O símbolo não precisa ser aquele especificado na caixa de diálogo Opções Regionais, e pode ser qualquer um dos caracteres mostrados na tabela seguinte.
| Símbolo de moeda | Nome da moeda | Valor Unicode (hexadecimal) |
$ | Símbolo de dólar (norte-americano) | 0024 |
£ | Símbolo de libra (Reino Unido) | 00A3 |
¤ | Símbolo de moeda (Universal) | 00A4 |
¥ | Símbolo de yen | 00A5 |
? | Marca de rúpia em bengali | 09F2 |
? | Símbolo de rúpia em bengali | 09F3 |
ß | Símbolo de bath tailandês | 03EF |
? | Símbolo de colón | 20A1 |
? | Símbolo de cruzeiro | 20A2 |
? | Símbolo de franco francês | 20A3 |
£ | Símbolo de lira | 20A4 |
? | Símbolo de naira | 20A6 |
P | Símbolo de peseta | 20A7 |
? | Símbolo de rúpia | 20A8 |
? | Símbolo de won | 20A9 |
¤ | Novo símbolo de sheqel | 20AA |
þ | Símbolo de dong | 20AB |
€ | Símbolo de euro | 20AC |
Observe que o símbolo de euro (valor hexadecimal 20AC) não é o mesmo que ?, o símbolo da moeda euro (ECU) (valor hexadecimal 20A0). Se você tentar usar ? em um valor de dinheiro, ocorrerá um erro.
Nomes de mês/dia e nomes de mês abreviados
Os nomes dos meses e dias na tabela syslanguages. Você pode recuperar as informações usando o procedimento armazenado sp_helplanguage, e exibir as seguintes colunas:
months
Uma lista delimitada por vírgula dos nomes dos meses, janeiro a dezembro
shortmonths
Uma lista delimitada por vírgula dos nomes abreviados dos meses, janeiro a dezembro
days
Uma lista delimitada por vírgula dos dias da semana, de segunda a sexta
Lidando com a interferência de localidade de COM
Embora o SQL Server tenha alguns recursos poderosos para lidar com valores de data/hora e moeda, se você usar qualquer serviço COM, tal como o ADO, para acessar o servidor, deverá fazer concessões para a operação desse serviço.
Por exemplo, talvez você tenha problemas para que o Visual Basic reconheça que um valor de número antecedido por qualquer um dos símbolos de moeda mostrados na tabela anterior é um símbolo de moeda. Talvez você também tenha problemas para que COM use corretamente os valores de data/hora armazenados em seqüências de caracteres.
Para solucionar corretamente esses problemas, você deve compreender exatamente quando o seu aplicativo está convertendo uma seqüência de caracteres para um valor de data/hora ou moeda. Primeiro, determine se a conversão ocorre no cliente ou no servidor e, em seguida, você pode decidir quais regras se aplicam.
O Office Access 2000 ADP é um exemplo de um cliente que converte valores de data, hora ou moeda. Como o Access está trabalhando através do OLE DB, todas as operações do Office Access 2000 são governadas pelas regras COM que usam as configurações regionais do computador cliente.
Os provedores OLE DB, tal como o Microsoft OLE DB Provider for SQL Server, converterão corretamente uma data COM válida para e de uma data do SQL Server. Recomendamos que você não use formatos de datas em seqüências de caracteres quando puder evitá-lo. Este tipo de funcionalidade pode quebrar quando a localidade do cliente for alterada.
Serviços de Geração de Relatórios do SQL Server 2005
O SQL Server 2005 Integrations Services substitui o Data Transformation Services do SQL Server 2000. O Integration Services oferece uma possibilidade extremamente aprimorada de importar, exportar e transformar dados multilíngües. O Integration Services oferece suporte à análise e à manipulação de dados multíngües, suporte a todas as localidades do Windows, além de fornecer opções de comparação especiais para a classificação e a comparação de dados da seqüência de caracteres.
Configurações de localidade nos pacotes do Integration Services
O Integration Services oferece suporte a localidades no nível do objeto do pacote, recipiente, tarefa e componente do fluxo de dados. Você também pode definir a localidade de manipuladores de eventos, além de algumas origens e destinos.
Um pacote pode usar várias localidades diferentes. Por exemplo, o pacote pode usar a localidade Inglês (Americano) enquanto uma tarefa do pacote usa a localidade Alemão (Alemanha) e outra usa a localidade Japonês (Japão).
Você pode usar qualquer localidade do Windows em um pacote do Integration Services. Você define a localidade quando constrói o pacote. A menos que o pacote use configurações para atualizar as propriedades de localidade, é garantido que o pacote se comporte da mesma forma quando implantado em computadores que talvez usem opções regionais e de idioma diferentes do ambiente de desenvolvimento.
Definindo a localidade
O Integration Services não usa a página de código para deduzir as regras específicas de localidade para classificar dados ou interpretar data, hora e dados decimais. Em vez disso, a transformação lê a localidade que é definida pela propriedade LocaleID no componente do fluxo de dados, tarefa do fluxo de dados, recipiente ou pacote.
Por padrão, a localidade de uma transformação é herdada de sua tarefa Data Flow, que por sua vez é herdada do pacote. Se a tarefa Data Flow estiver em um recipiente como o For Loop, ela herdará a localidade do recipiente.
Você também pode especificar uma localidade de um gerenciador de conexão Flat File e um gerenciador de conexão Multiple Flat Files.
Você pode alterar a localidade ou a página de código de um objeto usando o editor do objeto de fluxo de dados ou o objeto de fluxo de controle. No objeto do pacote, você deve definir as propriedades como LocaleID na janela de Propriedades.
Figura 14. Especificando a localidade de um pacote
Observe que a propriedade CodePage não está disponível no objeto do pacote. Isso acontece porque a página de código não é relevante para o objeto do pacote, mas somente para origens, destinos ou transformações.
Trabalhando com dados de arquivos simples
Ao trabalhar com dados de origem de arquivo simples, é importante compreender como o gerenciador de conexão Flat File interpreta os dados de arquivo simples. Se a origem do arquivo simples for Unicode, o gerenciador de conexão Flat File definirá todas as colunas como [DT_WSTR] com uma largura de coluna padrão 50. Se a origem do arquivo simples for ANSI, as colunas serão definidas como [DT_STR] com uma largura de coluna 50. Você provavelmente terá que alterar esses padrões para tornar os tipos de coluna da seqüência de caracteres mais apropriados para os seus dados. Para fazê-lo, examine o tipo de dados do destino no qual os dados serão gravados. Em seguida, escolha o tipo correto no gerenciador de conexão Flat File.
Esteja ciente de que ao importar ou exportar dados para arquivos simples, determinadas propriedades do pacote, a conexão e as tarefas de transformação de dados serão automaticamente definidas, com base na localidade. Você pode facilmente anular essas configurações, e talvez seja necessário fazer isso, caso os seus dados contenham informações que possam ser afetadas pelas configurações de localidade. Uma falha na alteração da localidade da origem ou do destino do arquivo simples pode ter conseqüências indesejadas.
Por exemplo, o tutorial do Integration Services que foi lançado com o SQL Server 2005 contém um cenário para a importação de dados de um arquivo simples. O arquivo contém uma coluna BirthDate que usa um dos formatos de data padrão da localidade EN-US. Se você executar esse tutorial em um computador que usa uma localidade padrão diferente, a execução do pacote que importa os dados pode falhar porque ele não analisa os dados de data. Neste caso, para fazer o pacote funcionar, tudo o que você precisa fazer é editar o pacote, os objetos do fluxo de dados e as origens ou destinos relacionados, para garantir que todos usam a localidade correta.
Figura 15. Especificando a localidade e a página de código de um arquivo simples
Analisando dados de texto
Quando o Integration Services carrega o texto de um arquivo simples ou outra origem, ele analisa o texto de acordo com um conjunto de rotinas de análise predefinidas: análise rápida ou análise padrão.
Análise rápida é um conjunto de rotinas de análise simples e rápido, que não oferece suporte a conversões de tipo de dados de localidade específica, mas oferece suporte somente aos formatos de data e hora usados com mais freqüência. A análise rápida não realiza a análise de localidade específica, não reconhece caracteres especiais em dados de moeda, além de não converter a representação hexadecimal ou científica de inteiros.
Análise padrão é um conjunto rico de rotinas de análise que oferece suporte a todas as conversões de tipo de dados fornecidas pelas APIs de conversão de tipo de dados de automação disponíveis em Oleaut32.dll e Ole2dsip.dll.
Ao criar um fluxo de dados, você pode especificar se as colunas de saída da transformação usam as rotinas de análise rápida mais ágeis, mas que não fazem distinção de localidade, que o Microsoft SQL Server 2005 Integration Services (SSIS) fornece ou as rotinas de análise padrão que fazem distinção de localidade.
Se o fluxo de dados do pacote requer a análise que faz distinção de localidade, recomenda-se a análise padrão em vez da análise rápida. Por exemplo, a análise rápida não reconhece os dados que fazem distinção de localidade que incluem símbolos decimais, como a vírgula, formatos de data diferentes de ano-mês-data e símbolos de moeda.
Para obter mais informações sobre os formatos de dados diferentes que têm suporte da análise rápida e da análise padrão, consulte Analisando dados no SQL Server 2005 Books Online.
A análise rápida é especificada no nível da coluna. Na origem Flat File e na transformação Data Conversion, você pode especificar a análise rápida em colunas de saída. Entradas e saídas podem incluir colunas que fazem distinção de localidade e que não fazem distinção de localidade. Entretanto, a análise rápida só está disponível durante o uso da origem Flat File ou da transformação Data Conversion.
Opções de comparação
A localidade fornece as regras básicas para comparar os dados da seqüência de caracteres em um fluxo de dados. Por exemplo, a localidade especifica a posição de classificação de cada letra do alfabeto. Entretanto, essas regras podem não ser suficientes para as comparações que você deseja realizar, e o Integration Services oferece suporte a um conjunto de opções de comparação avançadas que vão além das regras de comparação de uma localidade. Por exemplo, se você optar por ignorar caracteres de não-espaçamento, "a" e "á" serão equivalentes para fins de comparação.
As comparações de seqüência de caracteres são partes importantes de muitas das transformações realizadas pelo Integration Services, e essas comparações também são usadas na avaliação de expressões em variáveis e expressões de propriedade. Por exemplo:
| • | A transformação Conditional Split pode usar comparações de seqüência de caracteres para determinar para qual saída deve ser enviada a linha de dados. |
| • | A transformação Derived Column pode usar comparações de seqüência de caracteres em expressões para gerar novos valores de coluna. |
| • | As transformações Sort, Aggregate, Fuzzy Grouping e Fuzzy Lookup podem ser personalizadas para alterar a forma em que as seqüências de caracteres são comparadas no nível da coluna. Você deve especificar que uma pesquisa ignore a caixa, mas trate caracteres acentuados e sem acento como se fossem diferentes. |
Dependendo dos dados e da configuração da transformação, o processamento seguinte pode ocorrer durante a comparação dos dados da seqüência de caracteres:
| • | Convertendo dados para Unicode. Se os dados de origem já não forem Unicode, eles serão convertidos automaticamente para Unicode antes que a comparação ocorra. |
| • | Usando a localidade para aplicar regras específicas de localidade a fim de interpretar a data, a hora, os dados decimais e a ordem de classificação. |
| • | Aplicando opções de comparação no nível da coluna para alterar a diferenciação das comparações. |
Alterando opções de comparação
O Integration Services oferece suporte a um conjunto de opções de comparação avançadas que podem ser definidas no nível da coluna. Por exemplo, uma das opções de comparação permite que você ignore caracteres de não-espaçamento. O efeito desta opção é ignorar diacríticos como o acento, o que torna "a" e "á" idênticos para fins de comparação.
Você pode definir as opções de comparação seguintes nas transformações Sort, Aggregate, Fuzzy Grouping e Fuzzy Lookup:
| • | Ignorar caixa |
| • | Ignorar tipo de kana |
| • | Ignorar largura do caractere |
| • | Ignorar caracteres de não-espaçamento |
| • | Ignorar símbolos |
| • | Classificar pontuação como símbolos |
As transformações Fuzzy Grouping e Fuzzy Lookup também incluem a opção FullySensitive para comparar dados. Este sinalizador de comparação, disponível apenas no Advanced Editor, indica que todas as opções de comparação se aplicam.
Origens e destinos de dados
Em muitos casos, o Integration Services pode identificar a página de código correta da fonte de dados. Se o Integration Services fornecer uma página de código inesperada, ou se o pacote acessar uma fonte de dados usando um provedor que não fornece informações suficientes para determinar a página de código correta, você pode especificar uma página de código padrão na origem OLE DB e no destino OLE DB. As páginas de código padrão são usadas em vez das páginas de código que o Integration Services fornece.
Os arquivos não possuem páginas de código. Em vez disso, os gerenciadores de conexão Flat File e Multiple Flat Files que um pacote usa para se conectar aos dados do arquivo incluem uma propriedade para especificar a página de código do arquivo. A página de código pode ser definida somente no nível do arquivo, não no nível da coluna.
Dependendo das operações que a transformação realiza e da configuração da transformação, os dados da seqüência de caracteres podem ser convertidos para o tipo de dados DT_WSTR, que é uma representação Unicode dos caracteres da seqüência de caracteres.
Os dados da seqüência de caracteres que possuem o tipo de dados DT_STR são convertidos para Unicode através da página de código da coluna. O Integration Services oferece suporte às páginas de código no nível da coluna, e cada coluna pode ser convertida através de uma página de código diferente.
Conversão explícita de dados da seqüência de caracteres para Unicode
Os fluxos de dados dos pacotes extraem e carregam dados. Os fluxos de dados podem acessar dados em armazenamentos de dados heterogêneos, que talvez usem uma variedade de tipos de dados padrão e personalizados. Em um fluxo de dados, as origens do Integration Services fazem o trabalho de extração de dados, análise dos dados da seqüência de caracteres e conversão de dados para um tipo de dados do Integration Services. As transformações subseqüentes podem analisar dados para convertê-los para um tipo de dados diferente, ou criar cópias de coluna com tipos de dados diferentes. As expressões usadas em componentes também podem converter argumentos e operandos para tipos de dados diferentes. Finalmente, quando os dados são carregados em um armazenamento de dados, o destino pode analisar os dados para convertê-los para um tipo de dados que o destino use.
Quando os dados inserem um fluxo de dados em um pacote, o texto de origem que extrai os dados converte-os para um tipo de dados do Integration Services. Um tipo de dados numérico é atribuído aos dados numéricos, um tipo de dados de caracteres é atribuído aos dados da seqüência de caracteres e um tipo de dados data é atribuído às datas. Aos outros dados, tais como GUIDs e BLOBs (blocos de objeto binário grande), também são atribuídos os tipos de dados do Integration Services apropriados. Se os dados possuem um tipo de dados que não seja conversível para um tipo de dados do Integration Services, ocorrerá um erro.
Para obter mais informações sobre a conversão de dados em fluxos de dados, consulte Tipos de dados do Integration Services no SQL Server 2005 Books Online.
A transformação Data Conversion lhe oferece a habilidade de controlar as conversões — para alterar explicitamente as páginas de código, altere o formato ou converta os dados em uma coluna de entrada para um tipo de dados diferente. Você pode aplicar várias conversões a uma única coluna de entrada. Os dados convertidos podem substituir os dados originais, ou você pode copiá-los para uma nova coluna de saída a ser usada em componentes downstream.
Por exemplo, um pacote pode extrair dados de origens em vários idiomas e, em seguida, usar essa transformação para converter as colunas para o tipo de dados necessário ao armazenamento de dados de destino.
Usando a transformação Data Conversion, você pode realizar os seguintes tipos de conversões de dados:
| • | Alterar o tipo de dados. |
| • | Definir o tamanho da coluna dos dados da seqüência de caracteres e a precisão e a escala em dados numéricos. |
| • | Especificar uma página de código. |
A transformação Character Map é outro componente útil para a realização de conversões em dados de caracteres. Ela se aplica às funções de seqüência de caracteres, tal como a conversão de minúscula para maiúscula, para dados que possuem um tipo de dados de seqüência de caracteres.
A transformação Character Map pode converter os dados da coluna existentes ou adicionar uma coluna na saída da transformação e colocar os dados convertidos na nova coluna. Você pode aplicar conjuntos diferentes de operações de mapeamento à mesma coluna de entrada e colocar os resultados em colunas diferentes. Por exemplo, você pode converter a mesma coluna para maiúscula e minúscula, e colocar os resultados em duas colunas diferentes.
A transformação Character Map oferece suporte às seguintes operações de mapeamento:
| Operação | Descrição |
Reversão de byte | Reverte a ordem do byte. |
Largura total | Mapeia caracteres de meia largura para caracteres de largura total. |
Meia largura | Mapeia caracteres de largura total para caracteres de meia largura. |
Hiragana | Mapeia caracteres katakana para caracteres hiragana. |
Katakana | Mapeia caracteres hiragana para caracteres katakana. |
Uso de maiúsculas e minúsculas | Aplica o uso de maiúsculas e minúsculas em vez das regras do sistema. O uso de maiúsculas e minúsculas se refere à funcionalidade fornecida pela API Win32 para o mapeamento de caixa simples Unicode do turco e outras localidades. |
Minúscula | Converte os caracteres para minúsculo. |
Chinês simplificado | Mapeia os caracteres do chinês tradicional para os caracteres do chinês simplificado. |
Chinês tradicional | Mapeia os caracteres do chinês simplificado para os caracteres do chinês tradicional. |
Maiúsculo | Converte os caracteres para maiúsculo. |
Mais de uma operação pode ser realizada em uma transformação. Entretanto, algumas operações de mapeamento são mutuamente exclusivas. Em muitos casos, essas exclusões são senso comum: por exemplo, você não pode mapear katakana para hiragana ao mesmo tempo em que estiver mapeando hiragana para katakana. Para obter mais informações sobre mapeamentos exclusivos, consulte Transformação de mapa de caracteres no SQL Server 2005 Books Online.
Observação O mapeamento pode, em algumas circunstâncias, fazer com que os dados sejam truncados. Por exemplo, o truncamento pode ocorrer quando os caracteres de byte único são mapeados para caracteres com uma representação multibyte. Quando você realizar as conversões de dados, use os visualizadores de dados para monitorar as transformações nos dados, e use as saídas de erro para direcionar dados truncados ou incorretos para separar a saída. Para obter mais informações, consulte Manipulando erros em dados no SQL Server 2005 Books Online.
Suporte a caracteres suplementares no SSIS
O Integration Services manipula os pares substitutos de forma transparente. Ou seja, a não ser que uma fonte de dados, destino dos dados ou transformação esteja alterando o tamanho de uma cadeia de caracteres, os caracteres do par substituto devem ser manipulados da mesma forma que qualquer outro caractere Unicode. As funções ou recursos que retornam o tamanho de uma cadeia de caracteres devem tratar os caracteres do par substituto como dois caracteres Unicode indefinidos e separados. Os recursos que fazem isso são as funções LEN e SUBSTRING da cadeia de caracteres.
Para exibir caracteres suplementares, o usuário deve personalizar o Business Intelligence Development Studio para que ele use uma fonte que ofereça suporte às extensões desses caracteres. No entanto, como o suporte oferecido pelo SQL Server aos caracteres suplementares é somente como dados, e não metadados, os locais nos quais você pode precisar exibi-los estão limitados a visualizações de dados, à cláusula WHERE de consultas e assim por diante.
Alteração dinâmica da localidade com configurações
Se um pacote precisar usar diferentes localidades quando implantado em diferentes servidores, é possível criar configurações que forneçam as localidades atualizadas a serem usadas quando o pacote for executado.
As configurações são pares atributo-valor, os quais permitem que você defina propriedades de tempo de execução e variáveis externas ao ambiente de desenvolvimento. Ao incorporar as configurações no desenvolvimento, é possível criar pacotes que são flexíveis e fáceis de implantar e distribuir. O Integration Services oferece os seguintes tipos de configuração:
| • | Arquivo de configuração XML |
| • | Variável de ambiente |
| • | Entrada no Registro |
| • | Variável de pacote pai |
| • | Tabela do SQL Server |
Para fornecer flexibilidade adicional, o Integration Services oferece suporte ao uso de configurações indiretas. Isso significa que é possível usar uma variável de ambiente para especificar a localização da configuração, que, por sua vez, especifica os valores reais.
Um arquivo de configuração XML pode incluir configurações de várias propriedades e, em determinadas condições, pode armazenar configurações de vários pacotes.
Foram lançados vários tutoriais do Integration Services para orientá-lo no processo de criação e teste das configurações e no processo de criação de um utilitário de implantação para criar de novos pacotes que tenham as configurações dinâmicas. Recomendamos que você use esses tutoriais para saber mais sobre como atualizar dinamicamente as páginas de código, as opções de conversão ou outras configurações internacionais usando as configurações e implantando os pacotes.
Tutorial para a criação de um pacote ETL simples
O Tutorial para a criação de um pacote ETL simples o orientará nas tarefas a seguir.
| • | Criar um pacote simples do Integration Services e, em seguida, acrescentar o loop. |
| • | Introduzir o Assistente para configuração do pacote e descrever o formato das configurações XML. |
| • | Criar uma configuração de pacote que altere o diretório com os arquivos de texto para execução do loop. |
| • | Testar a configuração modificando o valor da variável externa ao ambiente de desenvolvimento e apontando a propriedade modificada a uma nova pasta de dados de amostra. Ao executar o pacote novamente, o arquivo de configuração atualizará o diretório de arquivos. |
Tutorial para a implantação de pacotes
O Tutorial para a implantação de pacotes será útil para você aprender as tarefas a seguir:
| • | Usar uma combinação de arquivos de configuração XML e configurações indiretas para atualizar as cadeias de caracteres de conexão dos arquivos de log, arquivos de texto e localizações dos arquivos XML e XSD que o pacote utiliza no tempo de execução. |
| • | Criar um pacote de implantação a ser utilizado para instalar os pacotes. O pacote de implantação consiste nos arquivos do pacote e em outros itens que você adicionou ao projeto do Integration Services, nas dependências do pacote que o Integration Services inclui automaticamente e no utilitário de implantação que você criou. |
| • | Executar o Assistente para instalação do pacote para instalar os pacotes e as respectivas dependências. Os pacotes são instalados no banco de dados msdb do SQL Server; os arquivos de suporte são instalados no sistema de arquivos. |
| • | Atualizar a configuração para utilizar os novos valores, os quais habilitam os pacotes para que sejam executados com êxito no novo ambiente. |
Recursos internacionais no SQL Server Analysis Services
O Microsoft SQL Server 2005 Analysis Services oferece suporte a todos os idiomas com suporte nos sistemas operacionais Microsoft Windows. O Analysis Services utiliza os identificadores de idiomas do Windows para especificar o idioma selecionado para instâncias e objetos do Analysis Services. Um identificador de idioma do Windows corresponde a uma combinação do idioma primário do Windows e dos identificadores de subidiomas. Por exemplo, se você selecionar Inglês (Estados Unidos) durante a Instalação, o identificador de idioma do Windows, 0x0409 (ou 1033), será especificado no elemento Idioma do arquivo das definições de configuração da instância do Analysis Services.
Traduções
Além de especificar o agrupamento e o idioma padrão utilizados por uma instância do Analysis Services, também é possível fornecer suporte a vários idiomas para objetos individuais do Analysis Services, inclusive cubos, grupos de medidas, dimensões, hierarquias e atributos, ao definir uma tradução associada a um objeto do Analysis Services.
É possível utilizar o Business Intelligence Development Studio para definir as traduções para tipos de conta, legenda, descrição de um banco de dados do Analysis Services. Quando você utilizar traduções, os aplicativos cliente podem receber os objetos do Analysis Services em um agrupamento e idioma diferente.
Se uma tradução de um identificador de idioma específico não for fornecida para um objeto do Analysis Services ou se um aplicativo cliente não especificar um identificador de idioma ao conectar-se a uma instância do Analysis Services, as configurações de idioma padrão e agrupamento para uma instância do Analysis Services especificarão as configurações utilizadas para os dados e metadados.
Lembre-se de que embora as traduções forneçam as informações para exibição dos nomes dos objetos do Analysis Services, os identificadores não são traduzidos. Para garantir a portabilidade em vários idiomas, use os identificadores e chaves dos objetos do Analysis Services em vez de legendas e nomes traduzidos. Por exemplo, use chaves membro em vez de nomes membro para as instruções e scripts MDX (Multidimensional Expressions, expressões multidimensionais).
Se um aplicativo cliente solicitar informações em um identificador de idioma especificado, a instância do Analysis Services tentará resolver os dados e metadados dos objetos do Analysis Services ao identificador de idioma mais próximo possível. Se o aplicativo cliente não especificar um idioma padrão, ou especificar o identificador de localidade neutro (0) ou identificador de idioma padrão do processo (1024), o Analysis Services utilizará o idioma padrão da instância para retornar dados e metadados dos objetos do Analysis Services.
Se o aplicativo cliente especificar um identificador de idioma que não seja o identificador de idioma padrão, a instância interage através de todas as traduções disponíveis para todos os objetos disponíveis. Se o identificador de idioma especificado coincidir com o identificador de idioma de uma tradução, o Analysis Services retornará essa tradução. Se não for localizada uma correspondência, o Analysis Services tentará usar um dos seguintes métodos para retornar traduções com um identificador de idioma o mais próximo possível do identificador de idioma especificado.
O Analysis Services tentará usar um identificador de idioma alternativo se não houver uma tradução definida para um dos identificadores de idioma a seguir:
| Identificador de idioma especificado | Identificador de idioma alternativo |
3076: Chinês (RAE de Hong Kong, República Popular da China) | 1028: Chinês (Taiwan) |
5124: Chinês (RAE de Macau) | 1028: Chinês (Taiwan) |
1028: Chinês (Taiwan) | Idioma padrão |
4100: Chinês (Cingapura) | 2052: Chinês (República Popular da China) |
2074: Croata | Idioma padrão |
3098: Croata (cirílico) | Idioma padrão |
Para todos os outros identificadores de idioma especificados, o Analysis Services extrai o idioma primário e recupera o identificador de idioma indicado pelo Windows como a melhor correspondência do idioma primário. Se não for localizada uma tradução, ou se o identificador de idioma especificado for a melhor correspondência para o idioma primário, o idioma padrão será utilizado.
Agrupamentos no Analysis Services
O Analysis Services utiliza agrupamentos do Windows para especificar o agrupamento selecionado para instâncias e objetos do Analysis Services. Quando você especificar um agrupamento do Windows para o Analysis Services, a instância do Analysis Services utilizará as mesmas páginas de código e as mesmas regras de classificação e comparação de um aplicativo que esteja sendo executado no computador em que você especificou a localidade associada. Por exemplo, o agrupamento francês do Windows para o Analysis Services coincide com os atributos de agrupamento da localidade francês do Windows.
Há mais localidades do Windows do que há agrupamentos definidos para o Analysis Services. Os nomes das localidades do Windows têm como base um identificador de idioma, como inglês, e um identificador de subidioma, como Estados Unidos ou Austrália. No entanto, muitos idiomas compartilham alfabetos e regras para classificação e comparação de caracteres em comum.
Por exemplo, 33 localidades do Windows, inclusive todas as localidades de português e inglês do Windows, utilizam a página de código Latin1 (1252) e seguem um conjunto comum de regras para classificação e comparação de caracteres. O agrupamento Latin1_General do Windows do SQL Server, com base nessa página de código e nas regras de classificação associadas, oferece suporte a todas as 33 dessas localidades do Windows. Além disso, as localidades do Windows especificam atributos que não são cobertos pelos agrupamentos do Windows no Analysis Services, como formatos de moeda, data e hora. Como os países e regiões, como Austrália e Estados Unidos, possuem diferentes formatos de moeda, data e hora, eles requerem diferentes agrupamentos do Windows. No entanto, como eles possuem o mesmo alfabeto e regras para classificação e comparação de caracteres, eles não requerem diferentes agrupamentos do Windows no Analysis Services.
Embora vários identificadores de idioma possam ser especificados para os objetos do Analysis Services, o mesmo agrupamento será utilizado para todos os objetos do Analysis Services, com uma única exceção, independentemente do identificador de idioma. A única exceção para essa funcionalidade é a propriedade CaptionColumn de um atributo em uma dimensão do banco de dados, para a qual você pode especificar um agrupamento do Windows no Analysis Services para agrupar os membros do atributo especificado.
Opções da ordem de classificação no Analysis Services
Se o mesmo idioma for utilizado por todos os usuários da sua instância do Analysis Services, selecione o agrupamento que oferece suporte ao idioma padrão especificado para a sua instância. Se vários idiomas forem utilizados, selecione um agrupamento que ofereça o melhor suporte aos requisitos dos vários idiomas. Por exemplo, se os usuários de sua instância falarem idiomas da Europa ocidental, selecione o agrupamento Latin1_General.
Várias opções de ordem da classificação podem ser aplicadas ao agrupamento especificado do Windows no Analysis Services, a fim de definir adicionalmente regras de classificação e comparação com base na diferenciação de maiúsculas e minúsculas, de caracteres com/sem acento, de caracteres kana e largura de caracteres. As opções da ordem de classificação são as mesmas para o mecanismo de bancos de dados do SQL Server: é possível definir diferenciação de maiúsculas e minúsculas, de largura de caracteres, de caracteres com/sem acento e de caracteres tipo kana.
Se utilizar o identificador de idioma Inglês (Estados Unidos) (0x0409 ou 1033) como o idioma padrão para a instância do Analysis Services, você poderá obter benefícios de desempenho adicional ao definir a propriedade de configuração EnableFast1033Locale. Essa é uma propriedade de configuração avançada que está disponível somente para esse identificador de idioma. A definição do valor dessa propriedade para true permite que o Analysis Services utilize um algoritmo mais rápido de hash e comparação da cadeia de caracteres.
Observação Um recurso que não tem suporte é a capacidade de ter diferentes agrupamentos em diferentes partes das estruturas hierárquicas de dados, as quais constituem um data warehouse. Embora em geral não seja útil na análise de dados, há casos, como o particionamento alfabético de dados, em que isso pode ser útil. Em tais casos, você precisaria ter outra forma de particionar os dados que definem explicitamente a ordem e as partições, e que não pressupõem a ordem das letras. Isso também seria muito útil na exibição de dados hierárquicos. Se precisar de tal funcionalidade, classifique o subconjunto de dados retornado da fonte OLAP.
Suporte a várias moedas
O Analysis Services fornece suporte à conversão de moeda em cubos que contêm várias moedas. Antes de definir uma conversão de moeda em um cubo, você deve primeiro definir, pelo menos, uma dimensão de moeda, uma dimensão de tempo e um grupo de medidas de taxa. A partir desses objetos, o Assistente do Business Intelligence pode recuperar os dados e metadados utilizados para construir a dimensão de moeda do relatório e criar um script MDX, a fim de fornecer a funcionalidade de conversão de moeda.
Antes de implementar as conversões de moeda, você deve primeiro definir o seguinte:
| Termo | Definição | ||||||
Moeda dinâmica | A moeda para a qual as taxas de câmbio serão inseridas no grupo de medidas de taxa. | ||||||
Moeda local | A moeda utilizada para armazenar as transações que as medidas de conversão terão como base. A moeda local pode ser identificada por um dos seguintes atributos:
| ||||||
Moeda do relatório da empresa | A moeda para a qual as transações são convertidas a partir da moeda dinâmica. | ||||||
Direção da taxa de câmbio | Indica se o multiplicador será aplicado à moeda dinâmica ou à moeda de amostra. A combinação da direção da taxa de câmbio e do tipo de conversão define a operação realizada nas medidas a serem convertidas. | ||||||
Partes convertidas | Especifica o escopo do cálculo de conversão da moeda. | ||||||
Tipo de conversão | Indica como as transações serão armazenadas e quantas moedas serão utilizadas na conversão.
|
Você pode utilizar, então, o Assistente do Business Intelligence para gerar um script MDX que utilize uma combinação de dados e metadados das dimensões, atributos e grupos de medida, a fim de converter medidas contendo dados de moeda. Para obter mais informações sobre como utilizar o assistente para criar conversões de moeda, consulte Trabalhando com conversões de moeda (SSAS) nos Manuais Online do SQL Server 2005.
Trabalhando com valores de data e hora no SSAS
Ao realizar comparações e operações mensais e por dia da semana, use as partes numéricas de data e hora em vez das cadeias de caracteres das partes de data e hora. As cadeias de caracteres das partes de data e hora são determinadas, em parte, pelo identificador de idioma especificado para a instância, bem como pela conversão da moeda fornecida pela instância para os membros da dimensão de tempo.
Aproveite as várias funções de data e hora no MDX para trabalhar com as dimensões de tempo. As funções de data e hora do Visual Basic for Applications (VBA) também são muito úteis para retornar partes numéricas de data e hora em vez das cadeias de caracteres de nome. Para aplicativos cliente, use as cadeias de caracteres literais de data e hora ao retornar resultados que serão exibidos para um usuário, pois as cadeias de caracteres geralmente são mais significativas do que uma representação numérica. No entanto, não crie nenhum código no qual a lógica dependa de os nomes serem exibidos em um idioma específico.
Suporte a XML no SQL Server 2005
O SQL Server 2005 introduz o SQLXML 4.0, o qual fornece a mesma funcionalidade básica que o SQLXML 3.0, além de atualizações adicionais para acomodar os novos recursos introduzidos no Microsoft SQL Server 2005.
O SQL Server 2005 oferece suporte ao tipo de dados xml, o que permite a você armazenar documentos e fragmentos XML em um banco de dados do SQL Server. Um fragmento XML é uma instância XML que está faltando em um elemento único de nível superior. É possível criar colunas e variáveis do tipo xml e armazenar as instâncias XML nelas, desde que a representação armazenada não exceda 2 GB. O tipo de dados xml e os métodos associados ajudam a integrar o XML na estrutura relacional do SQL Server.
XML e Unicode
O tipo de dado xml do SQL Server 2005 implementa o tipo de dado padrão xml do ISO SQL-2003. Portanto, ele pode armazenar documentos XML bem formados de versão 1.0, bem como os chamados fragmentos de conteúdo XML com nós de texto. O sistema que verifica se os dados estão bem formados não requer que a coluna seja vinculada a esquemas XML. Ele rejeitará os dados que não estiverem bem formados.
No SQL Server 2005, você pode gerar XML de várias formas: inserindo cadeias de caracteres de conversão, usando a instrução SELECT com a cláusula FOR XML, usando carregamento em massa ou atribuindo XML a uma constante da cadeia de caracteres. Para obter informações sobre como a cadeia de caracteres e os tipos binários interagem com a codificação de documento XML e como o analisador XML se comporta, consulte Gerando instâncias XML nos Manuais Online do SQL Server 2005.
Os documentos XML podem ser codificados de várias formas; por exemplo, UTF-8, UTF-16 ou Latin-1252. Há várias maneiras de se especificar uma codificação em XML:
| • | Se você formatar dados como XML em um objeto do fluxo ADO e, em seguida, mantiver o fluxo, será possível especificar uma codificação de saída e a codificação apropriada será marcada nos dados XML formatados. |
| • | É possível especificar uma codificação de saída em uma URL. |
| • | Os modelos XML podem especificar uma codificação. |
Mesmo se você não utilizar nenhum desses métodos, por padrão, o Unicode é compatível e funcionará corretamente.
Observação O tipo de dados xml do SQL Server 2005 trata o espaço em branco de forma diferente da descrição de espaço em branco na especificação XML 1.0. No SQL Server, o espaço em branco dentro do conteúdo de elemento não é considerado significativo se ocorrer em uma seqüência de dados de caracteres somente de espaço em branco delimitados pela marcação, como marcas de início e término, e sem entidades (as seções CDATA são ignoradas). Isso ocorre pelo fato de o analisador XML no SQL Server reconhecer somente um número limitado de subconjuntos DTD, como definido no XML 1.0. Para obter mais informações sobre os subconjuntos DTD limitados com suporte no SQL Server 2005, consulte CAST e CONVERT (Transact-SQL) nos Manuais Online do SQL Server 2005.
Updategrams
É possível modificar (inserir, atualizar ou excluir) dados em um banco de dados do Microsoft SQL Server 2005 a partir de um documento XML existente utilizando um updategram ou a função OPENXML do Transact-SQL. Os updategrams foram desenvolvidos para funcionar bem com texto multilíngüe e oferecer suporte a métodos para especificação de codificação.
A função OPENXML modifica um banco de dados ao fragmentar o documento XML existente e fornecer um conjunto de linhas, o qual pode ser passado para uma instrução INSERT, UPDATE ou DELETE. Com OPENXML, as operações são executadas diretamente nas tabelas do banco de dados. Portanto, o OPENXML é o mais apropriado sempre que provedores de conjuntos de linhas, como uma tabela, possam aparecer como uma fonte.
Como o OPENXML, um updategram permite que se insira, atualize ou exclua dados no banco de dados; no entanto, um updategram funciona com as exibições de XML fornecidas pelo esquema XSD anotado (ou um XDR). Por exemplo, as atualizações são aplicadas à exibição de XML fornecidas pelo esquema de mapeamento. O esquema de mapeamento, por sua vez, possui as informações necessárias para mapear elementos XML e atributos para as tabelas e colunas correspondentes do banco de dados. O updategram utiliza essas informações de mapeamento para atualizar as tabelas e colunas do banco de dados.
Acesso a dados para clientes XML
Para usar o SQLXML 4.0, é necessário ter o Microsoft SQL Native Client e o MDAC 2.6 ou posterior. Ao implantar um aplicativo que seja dependente do SQL Native Client, você precisará redistribuir o SQL Native Client com o seu aplicativo. Ao contrário do Microsoft Data-Access Components (MDAC), que agora é um componente do sistema operacional, o SQL Native Client é um componente do SQL Server 2005. Portanto, é importante instalar o SQL Server Native Client no seu ambiente de desenvolvimento e redistribuí-lo com o seu aplicativo.
Nas versões anteriores do SQLXML, a execução de consulta baseada em HTTP tinha suporte por meio do uso de diretórios virtuais IIS SQLXML e do filtro ISAPI SQLXML. No SQLXML 4.0, esses componentes foram removidos, pois agora é fornecida funcionalidade semelhante e sobreposta com os XML Web services nativos no SQL Server 2005. Se a solução requer os recursos aprimorados de inserção de dados do SQL Server 2005, como tipo de dados xml ou tipos de dados definidos pelo usuário (UDTs, user-defined data types) e acesso baseado na Web, será preciso utilizar outra solução, como as classes gerenciadas SQLXML ou outro tipo de manipulador de HTTP, como os XML Web Services nativos do SQL Server 2005.
Se não precisar dessas extensões de tipo do SQL Server 2005, continue utilizando o SQLXML 3.0 para conectar-se às instalações do SQL Server 2005. O suporte ISAPI do SQLXML 3.0 funcionará com o SQL Server 2005, mas não oferecerá suporte nem reconhecerá o tipo de dados xml, nem oferecerá suporte ao tipo UDT introduzido no SQL Server 2005.
Para obter uma introdução ao conjunto completo de recursos XML no SQL Server 2005, consulte Usando XML no SQL Server e Práticas recomendadas para XML nos Manuais Online do SQL Server 2005.
Para obter informações sobre como trabalhar com XML em aplicativos cliente, consulte Trabalhando com tipo de dados xml em aplicativos e Programação em SQLXML 4.0 nos Manuais Online do SQL Server 2005.
Aprimoramentos em pesquisas de texto completo
A pesquisa de texto completo do SQL Server 2005 inclui uma importante atualização do serviço de Pesquisa da Microsoft (MSSearch) para a versão 3.0. Esses aprimoramentos incluem os seguintes recursos:
| • | Desempenho de preenchimento do índice de texto completo imensamente aprimorado |
| • | Uma instância do MSSearch 3.0 por instância do SQL Server, permitindo a instalação “lado a lado” do mecanismo de texto completo em instâncias separadas |
| • | Aprimoramentos de consulta, inclusive o recurso de especificar o idioma |
| • | Suporte para indexação de texto completo e pesquisa de tipos de dados xml |
Várias instâncias de mecanismo de texto completo
O serviço Mecanismo de Pesquisa de Texto Completo da Microsoft para SQL Server (MSFTESQL) é baseado no serviço Pesquisa da Microsoft (MSSearch). No SQL Server 2005, um serviço separado é instalado por instância no Microsoft SQL Server. Isso significa que o SQL Server não precisa mais compartilhar o serviço MSSearch com outros produtos de serviços que utilizem o serviço MSSearch. Ter instâncias separadas do mecanismo de texto completo também simplifica o processo de gerenciamento e atualização dos servidores. Você pode instalar outros produtos que utilizem o serviço MSSearch, como o Microsoft SharePoint Portal Server, sem se preocupar que uma versão mais recente do serviço MSSearch afetará o comportamento da pesquisa de texto completo.
A atualização para a nova versão do MSSearch é feita durante a instalação do SQL Server 2005. Uma instância do SQL Server 2005 é instalada lado a lado com a versão antiga do SQL Server e os dados são migrados. Se a versão antiga do SQL Server tiver o serviço de Pesquisa de texto completo instalado, uma nova versão será automaticamente instalada.
Alterações de formato nos catálogos de texto completo
O formato dos catálogos de texto completo alterou significativamente no SQL Server 2005. Essa alteração requer que todos os catálogos de texto completo das versões anteriores do SQL Server sejam reconstruídos. A reconstrução ocorre automaticamente e não impede a conclusão da atualização. Conseqüentemente, a reconstrução dos catálogos de texto completo deve continuar depois da atualização.
Quando o catálogo de texto completo for reconstruído, uma nova pasta será criada no caminho em que o catálogo de texto completo estava originalmente localizado. Os arquivos associados aos catálogos reconstruídos de texto completo serão apresentados nessa nova pasta.
Opções específicas de idioma da pesquisa de texto completo
No Microsoft SQL Server 2005, as consultas de texto completo podem utilizar outros idiomas que não sejam o idioma padrão da coluna para a pesquisa de dados de texto completo. Desde que o idioma seja compatível e os seus recursos estejam instalados, o idioma especificado na cláusula language_term LANGUAGE de CONTAINS, a consulta CONTAINSTABLE, FREETEXT e FREETEXTTABLE será utilizado para quebra de palavras, lematização, dicionário de sinônimos e processamento de palavras de ruído.
Ao criar um índice de texto completo em uma coluna, você deve escolher o idioma para a coluna. Ao escolher um idioma, você definirá as opções para como o texto será indexado e, em seguida, indexado pelo mecanismo de texto completo. Essas opções incluem o seguinte:
| • | Uso de um separador de palavras específico ao idioma ou separador neutro de palavras. |
| • | Lematização com base no idioma |
O Apêndice E contém uma lista de idiomas que oferecem suporte à quebra de palavras ou à lematização específica de idioma. Todos os outros idiomas utilizam o mecanismo neutro de idioma. Nesse caso,a quebra de palavras utiliza o espaço em branco para separação e não é executada lematização.
Os separadores de palavras foram desenvolvidos basicamente para processar texto sem formatação; no entanto, se houver qualquer tipo de marcação (como HTML) no seu texto, você pode não obter a máxima precisão lingüística durante a indexação e a pesquisa. Nesse caso, você terá duas opções – o método preferido é simplesmente armazenar os dados de texto na coluna varbinary(max) e indicar o seu tipo de documento, de forma que possa ser filtrado.
Se você não puder armazenar os seus dados em uma coluna varbinary(max), considere o uso de um separador neutro de palavras. Se possível, você também pode adicionar os dados de marcação (como a marca "br" em HTML) às suas listas de palavras de ruído. Quando os dados não forem armazenados em uma coluna varbinary(max), não será executada a filtragem especial. Em vez disso, o texto passará pelo componente do separador de palavras da forma como está.
A configuração do identificador de localidade do agrupamento Unicode é utilizada em todos os tipos qualificados para indexação de texto completo (como char, nchar e assim por diante). Se você tiver especificado a ordem de classificação de uma coluna char, varchar ou text usando uma configuração de idioma diferente do idioma do identificador de localidade de agrupamento Unicode, o identificador de localidade de agrupamento Unicode ainda será utilizado durante a indexação e consulta de texto completo das colunas char, varchar e text.
Aprimoramentos em consultas de pesquisa de texto completo
A sintaxe de consulta de texto completo do SQL Server 2005 para as cláusulas CONTAINS, CONTAINSTABLE, FREETEXT e FREETEXTTABLE oferece suporte a um novo parâmetro <lcid> LANGUAGE, o qual pode ser utilizado para substituir o idioma de texto completo padrão da coluna com um idioma por nível de cláusula. Esse idioma por nível de cláusula determina qual separador de palavra, lematizador, dicionário de sinônimos e lista de palavras de ruído será utilizado para todos os termos da consulta de texto completo. O LCID é especificado como um valor numérico ou como uma cadeia de caracteres. O valor do parâmetro <lcid> LANGUAGE também pode ser especificado como uma variável do Transact-SQL, caso seja utilizado em uma cláusula de consulta de texto completo em um procedimento armazenado.
Por exemplo, você pode passar a cadeia de caracteres da pesquisa e o valor de idioma por nível de consulta como um procedimento armazenado, o qual obtém a cadeia de caracteres da pesquisa de um campo de entrada de texto e o idioma da consulta de uma lista de idiomas com suporte.
Para o código de amostra que demonstra o uso do parâmetro LCID, consulte Pesquisa de texto completo do SQL Server 2005: elementos internos e aprimoramentos na MSDN Library. Para obter mais informações sobre como utilizar o parâmetro LCID nas consultas de texto completo, consulte FREETEXT (Transact-SQL), FREETEXTTABLE (Transact-SQL), CONTAINS (Transact-SQL) ou CONTAINSTABLE (Transact-SQL) nos Manuais Online do SQL Server 2005.
Nas versões anteriores, o mapeamento de DocIds para valores da chave de texto completo era realizado no mecanismo de texto completo. No SQL Server 2005, esse processo foi movido para o mecanismo do banco de dados, no qual estratégias mais eficientes e consistentes de armazenamento em cache podem ser utilizadas. Essa migração, além dos aprimoramentos no mecanismo de consulta, devem acelerar as consultas de texto completo em relação às versões anteriores.
Nas versões anteriores, o mapeamento de DocIds para valores da chave de texto completo era realizado no mecanismo de texto completo. No SQL Server 2005, esse processo foi movido para o mecanismo do banco de dados, no qual estratégias mais eficientes e consistentes de armazenamento em cache podem ser utilizadas. Essa migração, além dos aprimoramentos no mecanismo de consulta, devem acelerar as consultas de texto completo em relação às versões anteriores.
Pesquisa de texto completo em dados XML
O SQL Server 2005 introduz um novo tipo de dados xml, o qual permite que você armazene um fragmento ou documento XML. A pesquisa de texto completo no SQL Server agora oferece suporte à criação de índices de texto completo em dados armazenados no tipo de dados xml, bem como consultas de texto completo em tais dados.
As consultas estão na granularidade do valor da coluna. Os predicados de texto completo emitidos em uma coluna XML indexada de texto completo retornam linhas, para as quais a cadeia de caracteres da pesquisa especificada existe em qualquer parte do conteúdo da coluna. Para obter mais informações, consulte Consultando as colunas varbinary(max) e xml nos Manuais Online do SQL Server 2005.
Interagindo com outros produtos de bancos de dados
Ao se trabalhar com outros sistemas de bancos de dados, a tarefa mais importante para os aplicativos internacionais é determinar a página de código e as regras desse sistema. Muitos métodos de acesso a dados do SQL Server utilizam COM e, portanto, usam os dados Unicode. O SQL Native Client também utiliza Unicode. Portanto, a informação mais importante para determinar se um aplicativo internacional será bem executado é saber se os produtos de banco de dados são compatíveis com Unicode.
Por exemplo, outros produtos de banco de dados, como Oracle e Sybase SQL Server, oferecem suporte a Unicode usando a codificação UTF-8. Em geral, isso não o afetará, pois os dados devem ser convertidos para UTF-16 usando o DB ADO/OLE antes de as informações serem visualizadas. Mas esteja atento a diferenças, caso tente interagir diretamente com os dados em tais produtos.
Determinados produtos oferecem suporte aos tipos de dados de caracteres nacionais, mas não os tratam como tipos de dados Unicode. Para tais bancos de dados, nchar e nvarchar são campos que você poderia utilizar para armazenar dados em japonês em um banco de dados de inglês dos EUA. O uso dos tipos de dados de caracteres nacionais para especificar o texto Unicode é específico do Microsoft SQL Server.
Portanto, se utilizar comandos, como OPENROWSET, executar as consultas em outro produto ou importar dados de outros sistemas, é muito importante que você saiba como as informações de texto internacional estão sendo manipuladas em outro banco de dados. Para obter mais informações, consulte Conectando-se ao mecanismo do banco de dados do SQL Server e Consultas distribuídas nos Manuais Online do SQL Server 2005.
Para obter mais informações como a conexão com fontes de dados externas no SQL Server 2005 para desenvolvimento de aplicativo, consulte os tópicos a seguir nos Manuais Online do SQL Server 2005:
SQL Server Analysis Services (SSAS)
SQL Server Integration Services (SSIS)
SQL Server Reporting Services
SQL Server Replication
Visão geral do driver JDBC
Trabalhando com fontes de dados (Analysis Services)
Conexões do Integration Services
Fontes de dados compatíveis com o Reporting Services
Replicação heterogênea de banco de dados
Acesso aos dados de objetos do banco de dados CLR
Conclusão
O Microsoft SQL Server 2005 tem como base um potente conjunto de recursos internacionais, os quais foram fornecidos no SQL Server 2000, e agrega suporte Unicode aprimorado e mais consistente, bem como integração com recursos multilíngües do sistema operacional Windows e CLR (Common Language Runtime). O SQL Server 2005 combina uma base sólida de suporte a bancos de dados internacionais com uma ampla variedade de ferramentas de desenvolvimento multilíngüe para finanças, comércio eletrônico e comunicação global.
Para obter mais informações:
Este artigo foi útil? Envie seus comentários! Em uma escala de 1 (insatisfatório) a 5 (excelente), como você classificaria este artigo?
Agradecimentos
Este artigo foi originalmente escrito por Michael Kaplan sobre o SQL Server 2000, com o auxílio de Michael Kung, gerente de programas do SQL Server; Peter Carlin, gerente de desenvolvimento do mecanismo relacional do SQL Server; e Fernando Caro, gerente líder do programa internacional. Foram fornecidas informações adicionais por Michael Rys, Euan Garden, Fadi Fakhouri, James Howey e Margaret Li. As informações sobre o suporte a agrupamento do SQL Server 7.0 e 2000 foram fornecidas por Julie Bennett, Cathy Wissink e John McConnell.
As informações atualizações sobre os recursos do SQL Server 2005 foram fornecidas pela equipe de Instrução do Usuário do SQL Server, com o auxílio de Fernando Caro e Nobuhiko Kishi.
Apêndice A: sufixos de agrupamento
| Sufixo | Significado |
_BIN | classificação binária |
_CI_AI | sem diferenciação de maiúsculas e minúsculas, sem diferenciação de caracteres com/sem acento, sem diferenciação de tipo kana, sem diferenciação de largura |
_CI_AI_WS | sem diferenciação de maiúsculas e minúsculas, sem diferenciação de caracteres com/sem acento, sem diferenciação de tipo kana, com diferenciação de largura |
_CI_AI_KS | sem diferenciação de maiúsculas e minúsculas, sem diferenciação de caracteres com/sem acento, com diferenciação de tipo kana, sem diferenciação de largura |
_CI_AI_KS_WS | sem diferenciação de maiúsculas e minúsculas, sem diferenciação de caracteres com/sem acento, com diferenciação de tipo kana, com diferenciação de largura |
_CI_AS | sem diferenciação de maiúsculas e minúsculas, com diferenciação de caracteres com/sem acento, sem diferenciação de tipo kana, sem diferenciação de largura |
_CI_AS_WS | sem diferenciação de maiúsculas e minúsculas, com diferenciação de caracteres com/sem acento, sem diferenciação de tipo kana, com diferenciação de largura |
_CI_AS_KS | sem diferenciação de maiúsculas e minúsculas, com diferenciação de caracteres com/sem acento, com diferenciação de tipo kana, sem diferenciação de largura |
_CI_AS_KS_WS | sem diferenciação de maiúsculas e minúsculas, com diferenciação de caracteres com/sem acento, com diferenciação de tipo kana, com diferenciação de largura |
_CS_AI | com diferenciação de maiúsculas e minúsculas, sem diferenciação de caracteres com/sem acento, sem diferenciação de tipo kana, sem diferenciação de largura |
_CS_AI_WS | com diferenciação de maiúsculas e minúsculas, sem diferenciação de caracteres com/sem acento, sem diferenciação de tipo kana, com diferenciação de largura |
_CS_AI_KS | com diferenciação de maiúsculas e minúsculas, sem diferenciação de caracteres com/sem acento, com diferenciação de tipo kana, sem diferenciação de largura |
_CS_AI_KS_WS | com diferenciação de maiúsculas e minúsculas, sem diferenciação de caracteres com/sem acento, com diferenciação de tipo kana, com diferenciação de largura |
_CS_AS | com diferenciação de maiúsculas e minúsculas, com diferenciação de caracteres com/sem acento, sem diferenciação de tipo kana, sem diferenciação de largura |
_CS_AS_WS | com diferenciação de maiúsculas e minúsculas, com diferenciação de caracteres com/sem acento, sem diferenciação de tipo kana, com diferenciação de largura |
_CS_AS_KS | om diferenciação de maiúsculas e minúsculas, com diferenciação de caracteres com/sem acento, com diferenciação de tipo kana, sem diferenciação de largura |
_CS_AS_KS_WS | com diferenciação de maiúsculas e minúsculas, com diferenciação de caracteres com/sem acento, com diferenciação de tipo kana, com diferenciação de largura |
Observação A diferenciação de tipo kana é definida por padrão. Em outras palavras, por padrão, katakana e hiragana são tratados da mesma forma. A não diferenciação de largura também é definida por padrão. Em outras palavras, por padrão, os caracteres de largura inteira e meia largura são tratados da mesma forma.
Apêndice B: localidades com suporte no Windows
Inglês (us_english) | Eslovaco (slovenèina) |
Alemão (Deutsch) | Esloveno (slovenski) |
Francês (Français) | Grego (åëëçíéêÜ) |
Japonês (“ú–{Œê) | Búlgaro (áúëãàðñêè) |
Dinamarquês (Dansk) | Russo (ðóññêèé) |
Espanhol (Español) | Turco (Türkçe) |
Italiano (Italiano) | Inglês britânico (British) |
Holandês (Nederlands) | Estoniano (eesti) |
Norueguês (Norsk) | Letão (latviešu) |
Português (Português) | Lituano (lietuviø) |
Finlandês (Suomi) | Português do Brasil (Português - Brasil) |
Sueco (Svenska) | Chinês tradicional (ÁcÅ餤¤å) |
Tcheco (èeština) | Coreano (Çѱ¹¾î) |
Húngaro (magyar) | Chinês simplificado (?‘Ì’†•¶) |
Polonês (polski) | Árabe (Árabe) |
Romeno (românã) | Tailandês (ä·Â) |
Croata (hrvatski) |
|
Apêndice C: ordens de classificação específicas do SQL
As ordens de classificação específicas do SQL também estão incluídas no SQL Server 2000. Tais ordens são mostradas na tabela a seguir. Muitas delas oferecem suporte a várias partes dos sufixos descritos anteriormente, mas nem todos os sufixos são compatíveis.
SQL_1xCompat_CP850 | SQL_Estonian_CP1257 | SQL_Latin1_General_Pref_CP437 |
SQL_AltDiction_CP1253 | SQL_Hungarian_CP1250 | SQL_Latin1_General_Pref_CP850 |
SQL_AltDiction_CP850 | SQL_Icelandic_Pref_CP1 | SQL_Latvian_CP1257 |
SQL_AltDiction_Pref_CP850 | SQL_Latin1_General_CP1 | SQL_Lithuanian_CP1257 |
SQL_Croatian_CP1250 | SQL_Latin1_General_CP1250 | SQL_MixDiction_CP1253 |
SQL_Czech_CP1250 | SQL_Latin1_General_CP1251 | SQL_Polish_CP1250 |
SQL_Danish_Pref_CP1 | SQL_Latin1_General_CP1253 | SQL_Romanian_CP1250 |
SQL_EBCDIC037_CP1 | SQL_Latin1_General_CP1254 | SQL_Scandinavian_CP850 |
SQL_EBCDIC273_CP1 | SQL_Latin1_General_CP1255 | SQL_Scandinavian_Pref_CP850 |
SQL_EBCDIC277_CP1 | SQL_Latin1_General_CP1256 | SQL_Slovak_CP1250 |
SQL_EBCDIC278_CP1 | SQL_Latin1_General_CP1257 | SQL_Slovenian_CP1250 |
SQL_EBCDIC280_CP1 | SQL_Latin1_General_CP437 | SQL_SwedishPhone_Pref_CP1 |
SQL_EBCDIC284_CP1 | SQL_Latin1_General_CP850 | SQL_SwedishStd_Pref_CP1 |
SQL_EBCDIC285_CP1 | SQL_Latin1_General_Pref_CP1 | SQL_Ukrainian_CP1251 |
SQL_AltDiction_CP1253 | SQL_Hungarian_CP1250 | SQL_Latin1_General_Pref_CP850 |
Apêndice D: idiomas com suporte no SQL Server 2005
Você pode visualizar essa mesma lista no SQL Server 2005 executando esta instrução:
select langid, alias, lcid, msglangid from sys.syslanguages
| Nome em inglês | Windows LCID | ID da Mensagem |
Inglês | 1033 | 1033 |
Alemão | 1031 | 1031 |
Francês | 1036 | 1036 |
Japonês | 1041 | 1041 |
Dinamarquês | 1030 | 1030 |
Espanhol | 3082 | 3082 |
Italiano | 1040 | 1040 |
Holandês | 1043 | 1043 |
Norueguês | 2068 | 2068 |
Português | 2070 | 2070 |
Finlandês | 1035 | 1035 |
Sueco | 1053 | 1053 |
Tcheco | 1029 | 1029 |
Húngaro | 1038 | 1038 |
Polonês | 1045 | 1045 |
Romeno | 1048 | 1048 |
Croata | 1050 | 1050 |
Eslovaco | 1051 | 1051 |
Esloveno | 1060 | 1060 |
Grego | 1032 | 1032 |
Búlgaro | 1026 | 1026 |
Russo | 1049 | 1049 |
Turco | 1055 | 1055 |
Inglês britânico | 2057 | 1033 |
Estoniano | 1061 | 1061 |
Letão | 1062 | 1062 |
Lituano | 1063 | 1063 |
Português do Brasil | 1046 | 1046 |
Chinês tradicional | 1028 | 1028 |
Coreano | 1042 | 1042 |
Chinês simplificado | 2052 | 2052 |
Árabe | 1025 | 1025 |
Tailandês | 1054 | 1054 |
Apêndice E: idiomas de texto completo acrescentados no SQL Server 2005
Esta lista também está disponível em Considerações internacionais sobre pesquisas de texto completo nos Manuais Online do SQL Server 2005. Para obter uma lista completa dos idiomas disponíveis para operações de indexação e consulta de texto completo, use sys.fulltext_languages.
| Identificador de localidade de agrupamento Unicode | Idioma para armazenamento de dados de texto completo |
Chinês Bopomofo (Taiwan) | Chinês tradicional |
Pontuação do chinês | Chinês simplificado |
Contagem de caracteres do chinês | Chinês simplificado |
Contagem de caracteres do chinês (Taiwan) | Chinês tradicional |
Holandês | Holandês |
Inglês do Reino Unido | Inglês do Reino Unido |
Francês | Francês |
Unicode geral | Inglês dos Estados Unidos |
Alemão | Alemão |
Catálogo telefônico em alemão | Alemão |
Italiano | Italiano |
Japonês | Japonês |
Unicode japonês | Japonês |
Coreano | Coreano |
Unicode Coreano | Coreano |
Espanhol (Espanha) | Espanhol |
Sueco/Finlandês | Sueco |
Apêndice F: agrupamentos atualizados no SQL Server 2005
Esta lista também está disponível em Configurações de agrupamentos na instalação nos Manuais Online do SQL Server 2005. Para obter a lista completa de agrupamentos compatíveis com uma instância do SQL Server 2005, use fn_helpcollations ().
| Nome do agrupamento anterior | Nome do novo agrupamento |
Japonês | Japanese_90 |
Chinês | Chinese_PRC_90 Chinese_PRC_Stroke Chinese_PRC_Stroke_90 Chinese_Taiwan_Bopomofo Chinese_Taiwan_Bopomofo_90 Chinese_Taiwan_Stroke Chinese_Taiwan_Stroke_90 |
Coreano | Korean_90 |
Hindi | (preterido nesta versão) |
Indiano | General_90 |