Detecteer inconsistenties in Rayons, Families en Subfamilies van artikels

Er kunnen inconsistenties optreden in de Rayons, Families en Subfamilies van artikels :

• sommige Rayons, Families en Subfamilies bestaan niet meer
• sommige items zijn gekoppeld aan een Familie waarvan de ouder niet de Rayon van het artikel is
• ...

Deze fouten zijn moeilijk te detecteren in de Mercator-interface omdat de dropdown-menu's alleen de mogelijke waarden tonen. Onjuiste waarden zijn daarom altijd onzichtbaar.

Het herstellen van deze gegevens kan alleen worden uitgevoerd door de foutieve artikels te identificeren door de volgende 3 stappen uit te voeren :

Identificeer artikels waarvoor de Rayons onjuist zijn

select s_id,s_id_rayon from STOCK 
    where (s_id_rayon<>'') and not exists(select * from RAYONS where s_id_rayon=id)

Identificeer artikels waarvoor de Families onjuist zijn

select s_id,s_id_rayon,s_id_famil from STOCK 
    where (s_id_famil<>'') and not exists(select * from FAMILLES where (s_id_famil=id) and (id_rayon=s_id_rayon))

Identificeer artikels waarvoor de Subfamilies onjuist zijn

select s_id,s_id_rayon,s_id_famil,s_id_ssfam from STOCK 
    where (s_id_ssfam<>'') and not exists(select * from SS_FAMIL where (s_id_ssfam=id) and (id_famille=s_id_famil))

Waarom legt Mercator deze controle niet standaard op aan de database?

De niet-gedetailleerde toepassing van de theorie zou op dit punt het stellen van beperkingen aan de database vereisen. De realiteit van wat een echte ERP is, evoluerend buiten een ideaal en theoretisch kader, heeft absoluut niets te maken met die van een programma en leidt er een hele geschiedenis achter, met inbegrip van in het bijzonder die van het ontwerp van Mercator's database, en opererend in echte bedrijven die niet bereid zijn om voortdurend functionele elementen te herzien zonder begrijpelijke reden voor de eindgebruiker. Continuïteit lijkt ons belangrijker dan de toepassing van principes. Mercator heeft een rapporteditor: hiermee kan iedereen zijn eigen rapporten opstellen, dus zijn eigen SQL-queries. Het is niet denkbaar om eenzijdig de veronderstellingen aan te passen waarmee iedereen, ook het personeel buiten Mercator, rekening heeft gehouden om deze verzoeken uit te voeren.

Het programmeerteam van Mercator heeft daarom deze situatie beoordeeld en daarop het volgende antwoord gegeven:

• In de meeste gevallen is het gebruik van Rayons, Families en Subfamilies zodanig dat de referentiële integriteit met betrekking tot relaties met deze tabellen als niet-strategisch kan worden beschouwd.
• Sinds altijd, dus sinds de DBF-versie van Mercator, is het niet verplicht dat een item wordt geassocieerd met een Rayon, een Familie of een Subfamilie. In dit geval is de informatie blanco (leeg).
• De plaatsing van externe sleutelbeperkingen zou een null waarde opleggen. Gezien het hierboven uiteengezette principe van continuïteit, is het niet denkbaar dat Mercator, van autoriteit, deze veronderstelling verandert.
• Bij zakelijk computergebruik heeft alles een prijs. Ook het misbruik van beperkingen. We weten dat een dergelijke wijziging een onmiskenbare impact zal hebben op de uploads, bijvoorbeeld door Excel-import, van bestanden met enkele tienduizenden artikelen (zeer frequent gebruik voor sommige gebruikers)

Daarom werd beslist om geen beperkingen op te leggen aan de relaties tussen enerzijds de artikelen en anderzijds de Rayons, Families en Subfamilies.

Hoe zet u toch deze beperkingen op?

Er doen zich twee scenario's voor. Ze kunnen gecombineerd worden.

1. Ofwel moeten alle artikels geassocieerd zijn met een Rayon, een Familie en een Subfamilie. U dit geval is het heel eenvoudig om voorwaarden voor externe sleutels in te stellen met de onderstaande SQL-code.

ALTER TABLE STOCK WITH CHECK ADD CONSTRAINT FK_STOCK_RAYONS FOREIGN KEY(S_ID_RAYON) REFERENCES RAYONS (ID)
CREATE UNIQUE INDEX FAMILLES_PK2 ON FAMILLES (ID,ID_RAYON) 
ALTER TABLE STOCK WITH CHECK ADD CONSTRAINT FK_STOCK_FAMILLES FOREIGN KEY(S_ID_FAMIL,S_ID_RAYON) REFERENCES FAMILLES (ID,ID_RAYON)
CREATE UNIQUE INDEX SS_FAMIL_PK2 ON SS_FAMIL (ID,ID_FAMILLE)
ALTER TABLE STOCK WITH CHECK ADD CONSTRAINT FK_STOCK_SS_FAMIL FOREIGN KEY(S_ID_SSFAM,S_ID_FAMIL) REFERENCES SS_FAMIL (ID,ID_FAMILLE)

2. Ofwel zijn sommige artikels mogelijk niet geassocieerd met een Rayon, een Familie en een Subfamilie. In dat geval kunnen twee oplossingen worden overwogen.

2a. Implementatie van een inhoudsbeperking die een scalaire functie aanroept. Dit kan een aanzienlijke invloed hebben op de prestaties tijdens massaverwerking (wijzigingen, imports, enz.) van artikelfiches.

U dient deze scalaire functie eerst te installeren :

CREATE FUNCTION dbo.RFS_EXISTS
(
	@id char(10),
	@id_parent char(10),
	@rfs char(1)
)
RETURNS bit
AS
BEGIN
	declare @r bit
	set @r=0
	if (@rfs='R') and exists(select * from RAYONS (NOLOCK) where id=@id)
	    set @r=1
	if (@rfs='F') and exists(select * from FAMILLES (NOLOCK) where id=@id and id_rayon=@id_parent)
	    set @r=1
	if (@rfs='S') and exists(select * from SS_FAMIL (NOLOCK) where id=@id and id_famille=@id_parent)
	    set @r=1
	return @r
END

Installeer vervolgens de beperkingen :

ALTER TABLE STOCK WITH CHECK ADD CONSTRAINT CHECK_RFS CHECK (
	(S_ID_RAYON='' or dbo.RFS_EXISTS(S_ID_RAYON, null, 'R')=1) and 
	(S_ID_FAMIL='' or dbo.RFS_EXISTS(S_ID_FAMIL, S_ID_RAYON, 'F')=1) and
	(S_ID_SSFAM='' or dbo.RFS_EXISTS(S_ID_SSFAM, S_ID_FAMIL, 'S')=1))

2b. Installatie van een trigger om te voorkomen dat artikels worden gekoppeld aan Rayons, Families of Subfamilies die niet bestaan. Deze oplossing biedt geen enkele validatie met betrekking tot de gegevens die al in de STOCK-tabel staan.

CREATE TRIGGER dbo.TR_STOCK_CHECK_RFS
on dbo.STOCK
FOR INSERT,UPDATE 
AS
BEGIN
	declare @msg varchar(100)

	if update(s_id_rayon) and exists(
		select * from inserted i where (i.s_id_rayon<>'') and not exists(select * from RAYONS r where r.id=i.s_id_rayon))
			set @msg='Rayon inexistant ! '

	if update(s_id_famil) and exists(
		select * from inserted i where (i.s_id_famil<>'') and not exists(select * from FAMILLES f where (f.id=i.s_id_famil) and (f.id_rayon=i.s_id_rayon)))
			set @msg=isnull(@msg,'')+ 'Famille inexistante ! '

	if update(s_id_ssfam) and exists(
		select * from inserted i where (i.s_id_ssfam<>'') and not exists(select * from SS_FAMIL s where (s.id=i.s_id_ssfam) and (s.id_famille=i.s_id_famil)))
			set @msg=isnull(@msg,'')+ 'Sous-famille inexistante !'

	if @msg is not null
		begin
			if @@TRANCOUNT > 0 ROLLBACK TRAN
			RAISERROR(@msg,16,1)
		end
END

Mercator heeft standaard triggers die het verwijderen / wijzigen van een gebruikte Rayon, Familie of Subfamilie verhinderen.