Base de données de partitionnement Horizontal vs Vertical - Différence entre la Normalisation et de la Ligne de Fractionnement?

Partitionnement est plutôt une notion générale et peut être appliquée dans de nombreux contextes. Lorsqu'il estime que la partition de l'relationnel données, il se réfère généralement à la décomposition de vos tables de ligne-sage (horizontalement) ou des colonnes (à la verticale).

Partitionnement Vertical, aka la ligne de fractionnement, utilise les mêmes techniques de fractionnement de base de la normalisation, mais en général le terme (verticale /horizontale) partitionnement de données se réfère à un optimisation physique alors que la normalisation est une optimisation sur le conceptuel niveau.

Puisque vous demandez une simple démonstration - supposons que vous disposez d'un tableau comme ceci:

create table data (
    id integer primary key, 
    status char(1) not null, 
    data1 varchar2(10) not null, 
    data2 varchar2(10) not null);

Une façon de partition data verticalement: Diviser comme suit:

create table data_main (
    id integer primary key,
    status char(1) not null,
    data1 varchar2(10) not null );

create table data_rarely_used (
    id integer primary key,
    data2 varchar2(10) not null,
    foreign key (id) references data_main (id) );

Ce type de partitionnement peut être appliqué, par exemple, lorsque vous avez rarement besoin de la colonne 2 dans vos requêtes. Partition data_main prendra moins de place, donc plein les analyses de la table sera plus rapide et il est plus probable qu'il s'inscrit dans le SGBD' cache de la page. Le revers de la médaille: Quand vous avez une requête à toutes les colonnes de data, vous obivously ont pour joindre les tables, ce qui sera plus cher que l'interrogation de la table d'origine.

Avis vous fractionnez les colonnes de la même manière que vous le feriez si vous normaliser les tables. Toutefois, dans ce cas data pourrait déjà être normalisé à 3FN (et même FNBC et 4NF), mais vous décider de continuer à le diviser pour la raison de l'optimisation physique.

Une façon de partition data horizontalement, à l'aide d'Oracle syntaxe:

create table data (
    id integer primary key, 
    status char(1), 
    data1 varchar2(10), 
    data2 varchar2(10) )
    partition by list (status) ( 
       partition active_data values ( 'A' ),
       partition other_data values(default) 
    );

Ce serait de dire au SGBD à l'interne de stockage de la table data en deux segments (deux tableaux), en fonction de la valeur de la colonne status. Cette façon de partitionnement data peut être appliqué, par exemple, quand on a l'habitude de requête uniquement les lignes d'une partition, par exemple, le statut de 'A' lignes (appelons-les lignes actives). Comme avant, les analyses complètes sera plus rapide (surtout si il y a seulement quelques lignes actives), les lignes (et les autres lignes resp.) sont stockés de manière contiguë (ils ne seront pas dispersés dans les pages qu'ils partagent avec les lignes d'un statut différent de la valeur, et il est plus probable que les lignes actifs seront dans le cache de la page.

La différence entre Normalisation et le fractionnement des mensonges dans le but de le faire.

Le principal objectif de la Normalisation est de supprimer les données redondantes Où, comme Le but de la Ligne de fractionnement est de séparer le moins de données requis.

par exemple:- Supposons que vous avez une table All_Details avec les colonnes id , Emp_name, Emp_address, Emp_phNo ,Emp_other_data, Company_Name , Company_Address , Company_revenue.

Maintenant, si vous voulez normaliser la table, vous devez créer deux nouveaux tableau Employee_Details et Company_Details et de garder une clé étrangère de company_id dans le tableau Employee_Details. de cette façon redondante des données de l'entreprise sera supprimé .

Maintenant parlons de la ligne de fractionnement. Dire que, même après la normalisation vous êtes seulement l'accès employee_name et emp_phNo mais vous n'êtes pas accès emp_address et emp_other_data si souvent. Donc, pour améliorer les performances de diviser la Employee_Details tableau en deux table de . table1 contenant fréquemment les données nécessaires( employee_name et emp_phNo ) et table2 contenant le moins fréquemment les données nécessaires( Emp_address, Emp_other_data) . À la fois de table aura le même unique_key colonne, de sorte que vous pouvez recréer une ligne de la table Employee_Details avec unique_key. Cela peut améliorer les performances de votre système drasticaly.