O padrão de dados de referência:extensível e flexível

Este diagrama de aparência incomum é uma visão panorâmica de um modelo de dados lógicos (LDM) contendo todos os tipos de referência para um sistema corporativo. É de uma instituição de ensino, mas pode se aplicar ao modelo de dados de qualquer tipo de organização. Quanto maior o modelo, mais tipos de referência você provavelmente descobrirá.

Por tipos de referência quero dizer dados de referência, ou valores de pesquisa, ou – se você quiser ser flash – taxonomias . Normalmente, os valores definidos aqui são usados ​​em listas suspensas na interface do usuário do seu aplicativo. Eles também podem aparecer como títulos em um relatório.

Este modelo de dados em particular tinha cerca de 100 tipos de referência. Vamos ampliar e ver apenas dois deles.

A partir deste diagrama de classes, vemos que todos os tipos de referência estendem o Root_Reference_Type . Na prática, isso significa apenas que todos os nossos tipos de referência têm os mesmos atributos de Alt_Sequence até Type_Key inclusive, como mostrado abaixo.

A solução de tabela de referência tradicional

A solução de duas mesas

O padrão de dados de referência extensível e flexível

Como gerenciar tudo isso

PROMPT Gender_Type
INSERT INTO reference_type (id, pretty_name, ref_type_key, description, id_range_from, id_range_to)
	VALUES (rety_seq.nextval, 'Gender Type', 'GENDER_TYPE', ' Identifies the gender of a person.', 13000000, 13999999);
INSERT INTO reference_value (id, pretty_name, description, effective_period_from, alt_sequence, reference_type_id)
	VALUES (13000010,'Female', 'Female', TRUNC(SYSDATE), 10, rety_seq.currval);
INSERT INTO reference_value (id, pretty_name, description, effective_period_from, alt_sequence, reference_type_id)
	VALUES (13000020,'Male', 'Male', TRUNC(SYSDATE), 20, rety_seq.currval);

PROMPT Party_Type
INSERT INTO reference_type (id, pretty_name, ref_type_key, description, id_range_from, id_range_to)
	VALUES (rety_seq.nextval, 'Party Type', 'PARTY_TYPE', A controlled list of reference values that identifies the type of party.', 23000000, 23999999);
INSERT INTO reference_value (id, pretty_name, description, effective_period_from, alt_sequence, reference_type_id)
	VALUES (23000010,'Organisation', 'Organisation', TRUNC(SYSDATE), 10, rety_seq.currval);
INSERT INTO reference_value (id, pretty_name, description, effective_period_from, alt_sequence, reference_type_id)
	VALUES (23000020,'Person', 'Person', TRUNC(SYSDATE), 20, rety_seq.currval);

Há uma linha em reference_type para cada subtipo LDM de Root_Reference_Type . A descrição em reference_type é retirado da descrição da classe LDM. Para Gender_Type , isso seria "Identifica o gênero de uma pessoa". Os snippets DML mostram as diferenças nas descrições entre tipo e valor, que podem ser usadas na interface do usuário ou em relatórios.

Você verá que reference_type chamado Gender_Type foi alocado um intervalo de 13000000 a 13999999 para seu reference_value.ids associado . Neste modelo, cada reference_type é alocado um intervalo de IDs exclusivo e não sobreposto. Isso não é estritamente necessário, mas nos permite agrupar IDs de valor relacionados. Isso meio que imita o que você obteria se tivesse mesas separadas. É bom ter, mas se você acha que não há nenhum benefício nisso, pode dispensá-lo.

Outra coluna que foi adicionada ao PDM é admin_role . Aqui está o porquê.

Quem são os administradores

INSERT INTO reference_value (id, pretty_name, description, effective_period_from, alt_sequence, reference_type_id)
	VALUES (13000040,'Not Known', 'Gender has not been recorded. Covers gender of unborn child, when someone has refused to answer the question or when the question has not been asked.', TRUNC(SYSDATE), 30, (SELECT id FROM reference_type WHERE ref_type_key = 'GENDER_TYPE'));

Isso rapidamente se torna um problema se tivermos a seguinte lógica incorporada em algum lugar:

IF ref_key = 'MALE' THEN
	RETURN 'M';
ELSE
	RETURN 'F';
END IF;

Claramente, a lógica "se você não é homem, deve ser mulher" não se aplica mais à taxonomia estendida.

É aqui que o admin_role coluna entra em jogo. Nasceu de discussões com os desenvolvedores sobre o design físico e funcionou em conjunto com a solução de interface do usuário. Mas se a solução de uma tabela por classe foi escolhida, então reference_type não teria existido. Os metadados contidos nele teriam sido codificados no aplicativo Gender_Type table – , que não é nem flexível nem extensível.

Somente usuários com o privilégio correto podem administrar a taxonomia. É provável que isso se baseie no conhecimento do assunto (PME ). Por outro lado, algumas taxonomias podem precisar ser administradas pela TI para permitir análise de impacto, testes completos e que quaisquer alterações de código sejam liberadas harmoniosamente a tempo para a nova configuração. (Se isso é feito por solicitações de mudança ou de alguma outra forma, depende da sua organização.)

Você deve ter notado que as colunas de auditoria created_by , created_date , updated_by e updated_date não são referenciados no script acima. Novamente, se você não estiver interessado neles, não precisará usá-los. Essa organização em particular tinha um padrão que obrigava a ter colunas de auditoria em todas as tabelas.

Acionadores:manter as coisas consistentes

--------------------------------------------------------------------------------
PROMPT >>> create REFERENCE_TYPE triggers
--------------------------------------------------------------------------------

CREATE OR REPLACE TRIGGER rety_bri
  BEFORE INSERT ON reference_type
  FOR EACH ROW
DECLARE
BEGIN
	IF (:new.id IS NULL) THEN
		:new.id := rety_seq.nextval;
	END IF;
	:new.created_by := function_to_get_user();
	:new.created_date := SYSDATE;
	:new.updated_by := :new.created_by;
	:new.updated_date := :new.created_date;
END rety_bri;
/

CREATE OR REPLACE TRIGGER rety_bru
  BEFORE UPDATE ON reference_type
  FOR EACH ROW
DECLARE
BEGIN
	:new.updated_by := function_to_get_user();
	:new.updated_date := SYSDATE;
END rety_bru;
/

--------------------------------------------------------------------------------
PROMPT >>> create REFERENCE_VALUE triggers
--------------------------------------------------------------------------------

CREATE OR REPLACE TRIGGER reva_bri
  BEFORE INSERT ON reference_value
  FOR EACH ROW
DECLARE
BEGIN
	IF (:new.type_key IS NULL) THEN
		-- create the type_key from pretty_name:
		:new.type_key := function_to_create_key(new.pretty_name);
	END IF;
	:new.created_by := function_to_get_user();
	:new.created_date := SYSDATE;
	:new.updated_by := :new.created_by;
	:new.updated_date := :new.created_date;
END reva_bri;
/

CREATE OR REPLACE TRIGGER reva_bru
  BEFORE UPDATE ON reference_value
  FOR EACH ROW
DECLARE
BEGIN
	-- once the type_key is set it cannot be overwritten:
	:new.type_key := :old.type_key;
	:new.updated_by := function_to_get_user();
	:new.updated_date := SYSDATE;
END reva_bru;
/

Minha formação é principalmente Oracle e, infelizmente, a Oracle limita os identificadores a 30 bytes. Para evitar exceder isso, cada tabela recebe um alias curto de três a cinco caracteres e outros artefatos relacionados à tabela usam esse alias em seus nomes. Então, reference_value o alias de é reva – os dois primeiros caracteres de cada palavra. Antes da inserção da linha e antes que a atualização de linha seja abreviada para bri e bru respectivamente. O nome da sequência reva_seq , e assim por diante.

Gatilhos de codificação manual como esse, tabela após tabela, exigem muito trabalho desmoralizante para os desenvolvedores. Felizmente, esses acionadores podem ser criados por meio da geração de código , mas isso é assunto para outro artigo!

A Importância das Chaves

SELECT … 
FROM …
INNER JOIN …
WHERE reference_value.id = 13000020

Você escreve:

SELECT … 
FROM …
INNER JOIN …
WHERE reference_value.type_key = 'MALE'

Basicamente, a chave explica claramente o que a consulta está fazendo .

Do LDM ao PDM, com espaço para crescer