question sur l'utilisation du for ($i = 0; $i < $result; $i++)

Jc · 06-12-2013 20:31:56

Je vais reprendre vos show create table, car il me semble que vous confondez les possibilités de votre modèle.

1) infos_gen_projets
CREATE TABLE IF NOT EXISTS `infos_gen_projets` (
`id_Projet` int(11) NOT NULL AUTO_INCREMENT,
`IG_acronyme` varchar(50) NOT NULL,
`IG_titre` varchar(100) NOT NULL,
`IG_ligne` varchar(150) NOT NULL,
`IG_appel` varchar(32) NOT NULL,
`IG_nbcontrat` mediumint(9) unsigned NOT NULL,
`IG_date-début` date NOT NULL,
`IG_durée` tinyint(2) unsigned NOT NULL,
`IG_prolongation` tinyint(2) unsigned DEFAULT NULL,
`IG_date-fin` date NOT NULL,
`IG_abstract` text NOT NULL,
`id_keywords` text NOT NULL,
`IG_logo` text,
`IG_contribce_requested` decimal(10,2) NOT NULL,
PRIMARY KEY (`id_Projet`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=3 ;

Ici un projet ne peut avoir qu'un seul acronyme et un acronyme peut appartenir à 1 ou plusieurs projets différents puisque aucun contrôle n'est fait au niveau du modèle.

2) projet_wp
CREATE TABLE IF NOT EXISTS `projet_wp` (
`id_Projet` int(11) NOT NULL,
`id_wp` int(11) NOT NULL AUTO_INCREMENT,
`WP_nb` tinyint(2) NOT NULL,
`WP_type` tinytext NOT NULL,
`WP_titre` text NOT NULL,
`WP_start` tinyint(2) NOT NULL,
`WP_end` tinyint(2) NOT NULL,
`WP_leader` tinyint(2) NOT NULL,
PRIMARY KEY (`id_wp`),
KEY `id_Projet` (`id_Projet`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=15 ;

Ici un wp ne peut être associé qu'à un seul projet et qu'à un seul wp_nb, la clé primaire n'étant pas composite.

3) projet_wp_objectifs
CREATE TABLE IF NOT EXISTS `projet_wp_objectifs` (
`id_object` int(11) NOT NULL AUTO_INCREMENT,
`id_wp` int(11) NOT NULL,
`WP_objectif` text NOT NULL,
PRIMARY KEY (`id_object`),
KEY `wp_id` (`id_wp`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=46 ;

Ici un objectif ne peut être associé qu'à un seul wp.

Ainsi par association, et dans le contexte qui vient d'être donné, votre première requête vous donne l'ensemble des projets pour un acronyme donné, et dans votre deuxième requête vous obtenez en fait l'ensemble des objectifs associés à l'ensemble des wp à la fois issus des projets obtenus précédemment et ayant un wp_nb donné.

Ce qui ne corresponds pas à ce que vous pensez avoir fait.
Et si ce que vous pensez avoir fait corresponds à votre réalité, vous avez la démonstration de ce que peut représenter une base de données incohérente lorsque aucune modélisation n'est effectuée correctement et que votre application est pilotée au niveau objet.

++

Darkangel · 06-12-2013 20:44:55

Bon et bien je pense avoir de mauvaises fondations d'après votre post.
En espérant pouvoir régulariser cela car je voudrais pouvoir faire les choses correctement.

Je vais donc tenter de répondre point par point afin d'essayer de clarifier ce qu'il en est:

Point 1:
Un projet ne peut effectivement n'avoir qu'un seul et même acronyme. Au pire celui-ci sera modifié mais s'est tout.
Néanmoins un acronyme peut effectivement être similaire entre deux projets / dans ce cas,c'est le numéro de contrat qui lui sera unique.

Point 2:
Un wp est propre à un projet
De même, celui-ci a son propre wp_nb.
Il faut il comprendre que chaque projets a une liste de wp qui ont eux mêmes des livrables et des objectifs.
Les wp sont pour tous les projets de type wp1, wp2 etc mais les titres et autres infos sont propre aux projets.

Point 3
Chaque wp a un ou plusieurs objectif mais dans ma table j'ai bien fait une ligne par objectif car je pensais cela comme le meilleur moyen mais a tort il faut croire.

Jc · 07-12-2013 01:07:48

Bonjour,

J'ai fait ce découpage pour que vous compreniez ce qui n'allait pas dans ce que vous avez fait. Mais ce qu'il faut que vous compreniez, c'est qu'à ce stade vous seul êtes capable de comprendre ce que vous avez fait et d'en juger.

En espérant pouvoir régulariser cela car je voudrais pouvoir faire les choses correctement.

Si tel est votre souhait et si vous voulez être aidé dans cet objectif, il faut tout reprendre à zéro, nous expliquer vos objectifs, ce que vous voulez faire, votre dictionnaire de données et vos règles de gestion, afin d'établir votre MCD (Modèle conceptuel de données).

Donc on vous écoute

EDIT:
Note

Néanmoins un acronyme peut effectivement être similaire entre deux projets / dans ce cas,c'est le numéro de contrat qui lui sera unique.

Attention! dans une base normalisée, deux entités distinctes homonymes doivent pouvoir être différenciées. Cette homonymie doit donc être levée au niveau projet.

Dernière modification par Jc (07-12-2013 02:42:25)

Darkangel · 07-12-2013 12:18:08

Bonjour,

Encore en phase de construction bien qu'ayant déjà codè certaines fonctions, je suis tout a fait près a réprendre tout si cela s'impose, ce qui semble être le cas.
Au moins j'apprendrai a a mieux faire pour les prochaines fois!

Je vais donc réfléchir a l'ensemble et vous soumettre une vue globale. Merci en tout as d'être à l'écoute de débutant comme moi!

A vous de me dire par contre si vous souhaitez que je continue a tout poster ici ou sur une adresse mail.
Je prépare ça pour le début de semaine, le week-end étant plus destiné a s'occuper des enfants

Jc · 11-12-2013 09:38:29

Bonjour,

Ici c'est mieux

Darkangel · 11-12-2013 12:06:24

Bonjour JC,

Je vous avais écrit un mail indiquant que j'avais procédé à un reverse engineering de ma base afin de diagnostiquer l'étendue des dégâts mais bon je vais donc tenter de détailler une vue globale de la base que j'ai par rapport à ce que souhaite (mais ça va faire plus long qu'en représentation graphique, )

Objet : Je souhaite développer une interface de gestion des projets que je gère afin de ma faciliter la vie à terme qui soit consultable et parfois modifiable par des utilisateurs et par ailleurs des utilisateurs d’autres organismes que le mien (projet collaboratif).

Pour se faire, j’ai créé une base de données dans laquelle j’ai plusieurs tables :

Je vais segmenter ma présentation en :

- tables principales
- Table de jointure
- Table annexes

Les tables principales

1) Une table que j’ai appelée « infos_gen_projets » dans laquelle je stocke les infos générales liées au projet à savoir la date de début, de fin, durée, numéro de contrat, acronyme etc.

CREATE TABLE IF NOT EXISTS `h2020`.`infos_gen_projets` (

  `id_Projet` INT(11) NOT NULL AUTO_INCREMENT,

  `IG_acronyme` VARCHAR(50) NOT NULL,

  `IG_titre` VARCHAR(100) NOT NULL,

  `IG_ligne` VARCHAR(150) NOT NULL,

  `IG_appel` VARCHAR(32) NOT NULL,

  `IG_nbcontrat` MEDIUMINT(9) UNSIGNED NOT NULL,

  `IG_date-debut` DATE NOT NULL,

  `IG_duree` TINYINT(2) UNSIGNED NOT NULL,

  `IG_prolongation` TINYINT(2) UNSIGNED NULL DEFAULT NULL,

  `IG_date-fin` DATE NOT NULL,

  `IG_abstract` TEXT NOT NULL,

  `id_keywords` TEXT NOT NULL,

  `IG_logo` TEXT NULL DEFAULT NULL,

  `IG_contribce_requested` DECIMAL(10,2) NOT NULL,

  PRIMARY KEY (`id_Projet`))

ENGINE = InnoDB

AUTO_INCREMENT = 3

DEFAULT CHARACTER SET = utf8;

2) J’ai ensuite crée une autre table « etab » dans laquelle je stocke les données lis aux organismes enregistrés avec nom, acronyme, adresse, siteweb etc.

CREATE TABLE IF NOT EXISTS `h2020`.`etab` (

  `id_Etab` INT(11) NOT NULL AUTO_INCREMENT,

  `ETAB_acronyme` TINYTEXT NOT NULL,

  `ETAB_nom` TINYTEXT NOT NULL,

  `ETAB_pic` INT(11) NOT NULL,

  `ETAB_nb` VARCHAR(15) NOT NULL,

  `ETAB_adresse` TINYTEXT NOT NULL,

  `ETAB_cp` CHAR(10) NOT NULL,

  `ETAB_ville` TINYTEXT NOT NULL,

  `ETAB_pays` TINYTEXT NOT NULL,

  `ETAB_logo` TEXT NOT NULL,

  `ETAB_siteweb` VARCHAR(255) NOT NULL,

  PRIMARY KEY (`id_Etab`))

ENGINE = InnoDB

AUTO_INCREMENT = 25

DEFAULT CHARACTER SET = utf8;

3) Enfin la table utilisateurs dans laquelle je stocke le login, mdp, mail etc sur les utilisateurs enregistrés, je devrais également à terme créer une autre table de gestion de droits.

CREATE TABLE IF NOT EXISTS `h2020`.`utilisateurs` (

  `id_Utilis` INT(11) NOT NULL AUTO_INCREMENT,

  `Utilis_login` VARCHAR(150) NOT NULL,

  `Utilis_mdp` CHAR(40) NOT NULL,

  `Utilis_grain` CHAR(32) NOT NULL,

  `Utilis_date_inscrip` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,

  `Utilis_debmail` VARCHAR(150) NOT NULL,

  `Utilis_srvmail` VARCHAR(25) NOT NULL,

  `Utilis_extmail` VARCHAR(25) NOT NULL,

  PRIMARY KEY (`id_Utilis`))

ENGINE = InnoDB

AUTO_INCREMENT = 2

DEFAULT CHARACTER SET = utf8;

Tables de jointure

1) Table de jointure entre Etab et Utilisateurs pour savoir à quel établissement appartient tel utilisateur

CREATE TABLE IF NOT EXISTS `h2020`.`jonc_etab_utilisateur` (

  `id_jonc` INT(11) NOT NULL AUTO_INCREMENT,

  `id_Utilis` INT(11) NOT NULL,

  `id_Etab` INT(11) NOT NULL,

  PRIMARY KEY (`id_jonc`),

  INDEX `id_Utilis` (`id_Utilis` ASC, `id_Etab` ASC),

  INDEX `id_Etab` (`id_Etab` ASC),

  CONSTRAINT `jonc_etab_utilisateur_ibfk_1`

    FOREIGN KEY (`id_Utilis`)

    REFERENCES `h2020`.`utilisateurs` (`id_Utilis`)

    ON DELETE CASCADE

    ON UPDATE CASCADE,

  CONSTRAINT `jonc_etab_utilisateur_ibfk_2`

    FOREIGN KEY (`id_Etab`)

    REFERENCES `h2020`.`etab` (`id_Etab`)

    ON DELETE CASCADE

    ON UPDATE CASCADE)

ENGINE = InnoDB

AUTO_INCREMENT = 2

DEFAULT CHARACTER SET = utf8;

2) La table de jointure entre Etab et infos gen projets
Celle-ci est assez complète car elle stocke beaucoup d’infos.
Elle permet de savoir déjà quel etab est associé à tel projet, avec quel statut (partenaire ou coordonnateur), le numéro (numéro de partenaire du projet), la date d’entrée de sortie, le responsable admin, scientifique, juridique

CREATE TABLE IF NOT EXISTS `h2020`.`jonc_etab_projets` (

  `id_jonc` INT(11) NOT NULL AUTO_INCREMENT,

  `id_Etab` INT(11) NOT NULL,

  `id_Projet` INT(11) NOT NULL,

  `JONC_EP_statut` ENUM('coord','partn') NOT NULL,

  `JONC_EP_nb` TINYINT(2) UNSIGNED NOT NULL,

  `JONC_EP_entry` TINYINT(2) UNSIGNED NOT NULL,

  `JONC_EP_exit` TINYINT(2) UNSIGNED NOT NULL,

  `JONC_EP_contrib_requested` DECIMAL(10,2) NOT NULL,

  `JONC_EP_overheads_particuliers` TINYINT(2) NOT NULL,

  `JONC_EP_titre_scientifique` VARCHAR(10) NOT NULL,

  `JONC_EP_gender_scientifique` ENUM('M','F') NOT NULL,

  `JONC_EP_prenom_scientifique` VARCHAR(30) CHARACTER SET 'latin1' COLLATE 'latin1_general_ci' NOT NULL,

  `JONC_EP_nom_scientifique` VARCHAR(30) CHARACTER SET 'latin1' COLLATE 'latin1_general_ci' NOT NULL,

  `JONC_EP_dbemail_scientifique` VARCHAR(150) CHARACTER SET 'ascii' NOT NULL,

  `JONC_EP_srvemail_scientifique` VARCHAR(25) NOT NULL,

  `JONC_EP_extemail_scientifique` VARCHAR(25) NOT NULL,

  `JONC_EP_titre_admin` VARCHAR(10) NOT NULL,

  `JONC_EP_gender_admin` ENUM('M','F') NOT NULL,

  `JONC_EP_prenom_admin` VARCHAR(30) NOT NULL,

  `JONC_EP_nom_admin` VARCHAR(30) NOT NULL,

  `JONC_EP_dbemail_admin` VARCHAR(150) CHARACTER SET 'ascii' NOT NULL,

  `JONC_EP_srvemail_admin` VARCHAR(50) NOT NULL,

  `JONC_EP_extemail_admin` VARCHAR(50) NOT NULL,

  `JONC_EP_titre_judiciaire` VARCHAR(10) NOT NULL,

  `JONC_EP_gender_judiciaire` ENUM('M','F') NOT NULL,

  `JONC_EP_prenom_judiciaire` VARCHAR(30) NOT NULL,

  `JONC_EP_nom_judiciaire` VARCHAR(30) NOT NULL,

  `JONC_EP_dbemail_judiciaire` VARCHAR(150) CHARACTER SET 'ascii' NOT NULL,

  `JONC_EP_srvemail_judiciaire` VARCHAR(50) NOT NULL,

  `JONC_EP_extemail_judiciaire` VARCHAR(50) NOT NULL,

  PRIMARY KEY (`id_jonc`),

  INDEX `id_Projet` (`id_Projet` ASC),

  INDEX `id_Etab` (`id_Etab` ASC),

  CONSTRAINT `jonc_etab_projets_ibfk_1`

    FOREIGN KEY (`id_Etab`)

    REFERENCES `h2020`.`etab` (`id_Etab`)

    ON DELETE CASCADE

    ON UPDATE CASCADE,

  CONSTRAINT `jonc_etab_projets_ibfk_2`

    FOREIGN KEY (`id_Projet`)

    REFERENCES `h2020`.`infos_gen_projets` (`id_Projet`)

    ON DELETE CASCADE

    ON UPDATE CASCADE)

ENGINE = InnoDB

AUTO_INCREMENT = 26

DEFAULT CHARACTER SET = utf8;

Table annexes

1) Liées à la table Etab

- La table « finances » dans laquelle je stock le numéro de tva, swift, iban

CREATE TABLE IF NOT EXISTS `h2020`.`etab_finances` (

  `id_Finances` INT(11) NOT NULL AUTO_INCREMENT,

  `id_Etab` INT(11) NOT NULL,

  `FIN_tva` CHAR(13) CHARACTER SET 'ascii' COLLATE 'ascii_bin' NOT NULL,

  `FIN_iban` CHAR(31) CHARACTER SET 'ascii' COLLATE 'ascii_bin' NOT NULL,

  `FIN_swift` CHAR(11) CHARACTER SET 'ascii' COLLATE 'ascii_bin' NOT NULL,

  PRIMARY KEY (`id_Finances`),

  INDEX `id_Etab` (`id_Etab` ASC),

  CONSTRAINT `etab_finances_ibfk_1`

    FOREIGN KEY (`id_Etab`)

    REFERENCES `h2020`.`etab` (`id_Etab`)

    ON DELETE CASCADE

    ON UPDATE CASCADE)

ENGINE = InnoDB

AUTO_INCREMENT = 26

DEFAULT CHARACTER SET = utf8;

- La table « overheads » dans laquelle je stocke le % des coûts indirects à appliquer suivant l’établissement et le programme.

CREATE TABLE IF NOT EXISTS `h2020`.`etab_overheads` (

  `id_Etab` INT(11) NOT NULL,

  `id_overheads` INT(11) NOT NULL AUTO_INCREMENT,

  `OVH_programme` ENUM('FP7','H2020') NOT NULL,

  `OVH_montant` DECIMAL(10,3) NOT NULL,

  PRIMARY KEY (`id_overheads`),

  INDEX `id_Etab` (`id_Etab` ASC),

  CONSTRAINT `etab_overheads_ibfk_1`

    FOREIGN KEY (`id_Etab`)

    REFERENCES `h2020`.`etab` (`id_Etab`)

    ON DELETE CASCADE

    ON UPDATE CASCADE)

ENGINE = InnoDB

AUTO_INCREMENT = 26

DEFAULT CHARACTER SET = utf8;

- La table « representatives » dans laquelle je stocke les infos sur les représentants officiels de chaque établissement : nom, prénom, titre etc.

CREATE TABLE IF NOT EXISTS `h2020`.`etab_representatives` (

  `id_Repr` INT(11) NOT NULL AUTO_INCREMENT,

  `id_Etab` INT(11) NOT NULL,

  `REPR_titre` TEXT NOT NULL,

  `REPR_gender` ENUM('M','F') NOT NULL,

  `REPR_prenom` TEXT NOT NULL,

  `REPR_nom` TEXT NOT NULL,

  `REPR_fonction` TEXT NOT NULL,

  `REPR_phone1` VARCHAR(20) NOT NULL,

  `REPR_phone2` VARCHAR(20) NOT NULL,

  `REPR_fax` VARCHAR(20) NOT NULL,

  `REPR_dbemail` VARCHAR(150) CHARACTER SET 'ascii' NOT NULL,

  `REPR_srvemail` VARCHAR(50) NOT NULL,

  `REPR_extemail` VARCHAR(50) NOT NULL,

  `REPR_justif` TEXT NOT NULL,

  PRIMARY KEY (`id_Repr`),

  INDEX `id_Etab` (`id_Etab` ASC),

  CONSTRAINT `etab_representatives_ibfk_1`

    FOREIGN KEY (`id_Etab`)

    REFERENCES `h2020`.`etab` (`id_Etab`)

    ON DELETE CASCADE

    ON UPDATE CASCADE)

ENGINE = InnoDB

AUTO_INCREMENT = 42

DEFAULT CHARACTER SET = utf8;

- La table « Legal » dans laquelle je stocke les infos liées aux statuts de l’établissement

CREATE TABLE IF NOT EXISTS `h2020`.`etab_legal` (

  `id_Etab` INT(11) NOT NULL,

  `LEG_natural` ENUM('oui','non') NOT NULL,

  `LEG_legpers` ENUM('oui','non') NOT NULL,

  `LEG_nonprof` ENUM('oui','non') NOT NULL,

  `LEG_researchorg` ENUM('oui','non') NOT NULL,

  `LEG_pubbod` ENUM('oui','non') NOT NULL,

  `LEG_intorg` ENUM('oui','non') NOT NULL,

  `LEG_intorgeo` ENUM('oui','non') NOT NULL,

  `LEG_educ` ENUM('oui','non') NOT NULL,

  `LEG_enterp` ENUM('oui','non') NOT NULL,

  `LEG_sme` ENUM('oui','non') NOT NULL,

  UNIQUE INDEX `id_Etab` (`id_Etab` ASC),

  CONSTRAINT `etab_legal_ibfk_1`

    FOREIGN KEY (`id_Etab`)

    REFERENCES `h2020`.`etab` (`id_Etab`)

    ON DELETE CASCADE

    ON UPDATE CASCADE)

ENGINE = InnoDB

DEFAULT CHARACTER SET = utf8;

2) Liées à la table Projet

- La table « Projets WP » dans laquelle je stocke les infos liées aux work-packages des projets

CREATE TABLE IF NOT EXISTS `h2020`.`projet_wp` (

  `id_Projet` INT(11) NOT NULL,

  `id_wp` INT(11) NOT NULL AUTO_INCREMENT,

  `WP_nb` TINYINT(2) NOT NULL,

  `WP_type` TINYTEXT NOT NULL,

  `WP_titre` TEXT NOT NULL,

  `WP_start` TINYINT(2) NOT NULL,

  `WP_end` TINYINT(2) NOT NULL,

  `WP_leader` TINYINT(2) NOT NULL,

  PRIMARY KEY (`id_wp`),

  INDEX `id_Projet` (`id_Projet` ASC),

  CONSTRAINT `projet_wp_ibfk_1`

    FOREIGN KEY (`id_Projet`)

    REFERENCES `h2020`.`infos_gen_projets` (`id_Projet`)

    ON DELETE CASCADE

    ON UPDATE CASCADE)

ENGINE = InnoDB

AUTO_INCREMENT = 15

DEFAULT CHARACTER SET = utf8;

- La table « WP objectifs »rattaché à WP dans laquelle je stocke les objectifs des Work package (1 ou plusieurs par WP)

CREATE TABLE IF NOT EXISTS `h2020`.`projet_wp_objectifs` (

  `id_object` INT(11) NOT NULL AUTO_INCREMENT,

  `id_wp` INT(11) NOT NULL,

  `WP_objectif` TEXT NOT NULL,

  PRIMARY KEY (`id_object`),

  INDEX `wp_id` (`id_wp` ASC),

  CONSTRAINT `projet_wp_objectifs_ibfk_1`

    FOREIGN KEY (`id_wp`)

    REFERENCES `h2020`.`projet_wp` (`id_wp`)

    ON DELETE CASCADE

    ON UPDATE CASCADE)

ENGINE = InnoDB

AUTO_INCREMENT = 46

DEFAULT CHARACTER SET = utf8;

- La table « Deliverables » rattaché à WP dans laquelle je stocke les infos liés aux déliverables de chacun des work packages du projet

CREATE TABLE IF NOT EXISTS `h2020`.`projet_wp_deliverables` (

  `id_wp` INT(11) NOT NULL,

  `id_deliv` INT(11) NOT NULL AUTO_INCREMENT,

  `DELIV_nb` VARCHAR(5) NOT NULL,

  `DELIV_titre` TEXT NOT NULL,

  `DELIV_leader` TINYINT(2) NOT NULL,

  `DELIV_pm` TINYINT(3) NOT NULL,

  `DELIV_nature` TINYTEXT NOT NULL,

  `DELIV_dissem` TINYTEXT NOT NULL,

  `DELIV_date` TINYINT(2) NOT NULL,

  PRIMARY KEY (`id_deliv`),

  INDEX `id_wp` (`id_wp` ASC),

  CONSTRAINT `projet_wp_deliverables_ibfk_2`

    FOREIGN KEY (`id_wp`)

    REFERENCES `h2020`.`projet_wp` (`id_wp`)

    ON DELETE CASCADE

    ON UPDATE CASCADE)

ENGINE = InnoDB

DEFAULT CHARACTER SET = utf8;

Et enfin la table « compte » rattaché à projet dans laquelle je stocke le numéro de compte, le solde, etc… du projet

CREATE TABLE IF NOT EXISTS `h2020`.`projet_comptes` (

  `id_cpt` INT(11) NOT NULL AUTO_INCREMENT,

  `id_Projet` INT(11) NOT NULL,

  `CPT_nb` VARCHAR(15) NOT NULL,

  `CPT_solde` INT(11) NOT NULL,

  `CPT_solde_date` DATE NOT NULL,

  PRIMARY KEY (`id_cpt`),

  INDEX `id_Projet` (`id_Projet` ASC),

  CONSTRAINT `projet_comptes_ibfk_1`

    FOREIGN KEY (`id_Projet`)

    REFERENCES `h2020`.`infos_gen_projets` (`id_Projet`)

    ON DELETE CASCADE

    ON UPDATE CASCADE)

ENGINE = InnoDB

AUTO_INCREMENT = 4

DEFAULT CHARACTER SET = utf8;

Voilà ma structure de base actuelle qui d’après vos précédentes remarques ne doit pas être adéquate.
dans l'attente de votre retour pour en discuter

Darkangel · 11-12-2013 13:38:14

si cela peut aider, voila la représentation graphique:
https://drive.google.com/file/d/0B8uGkm … sp=sharing

si je me base sur mon modèle conceptuel et afin de vérifier les points 1 par 1:
je ne suis pas certain par ailleurs que mes datatype de champs sont partout adéquat

1) Un établissement à plusieurs utilisateurs et un utilisateur peut faire partie de plusieurs établissement donc sommes nous bien d'accord qu'une table associative s'impose? ce que j'ai fais me semble ici logique. Néanmoins, question: Pourrais-je au sein de cette table associative indiquer les niveaux d'accès ou est-ce préférable de procéder autrement?

2) Un établissement n'a pas plusieurs données financières donc par conclusion il s'agit d'une relation 1:1. est ce ok?

3) Un établissement peut avoir plusieurs représentants légaux donc relation 1:n. est ce ok?

4) Un établissement n'a qu'un type de statut donc relation 1:1 contrairement à ma modélisation qui indique une relation 1:n? mais je n'ai jamais demandé ça quand j'ai construit ma table...enfin je ne pense pas...

5) Un établissement peut avoir plusieurs projets et un projet peut avoir comme partenaire plusieurs établissement donc table associative je pense.
Cependant je ne sais pas si j'ai bien fais de mettre autant de donnée dans cette table d'autant que de base il y a bien qu'un seul contact admin, financier ou juridique mais si je veux pouvoir rajouter d'autres personnes associées disons cela pourra un jour me poser problème. Dois je donc prévoir de créer des tables 1:N liées avec ma table de jointure, 1 pour les contacts administratifs, 1 pour les contacts juridiques et enfin une pour les contacts scientifiques??

6) Contrairement à ce que me donne ma modélisation et après réflexion un projet peut avoir plusieurs comptes avec un solde différent donc il aurait fallu faire une relation 1:N je présume et non 1:1, comment puis je modifier cela dans ma base existante?

7) 1 projet à plusieurs Wp (Work Package) donc 1:n comme je l'ai fait à priori

8) chaque WP à plusieurs objectifs et plusieurs deliverables donc pour chacun des cas il faut bien faire une relation 1:N, non?

une fois ces points validés, je pense déja que j'aurais avancé un peu... je crois

Dernière modification par Darkangel (11-12-2013 16:01:54)

Jc · 14-12-2013 12:12:09

Bonjour,

Merci pour le post et le graphique également, ca fait gagner du temps.
Par contre, vu le travail que vous avez fourni, je me dois de vous répondre d'une manière détaillée, et il y a beaucoup de choses à dire et de questions à soulever.
J'essaye de vous faire cela demain

A plus tard et merci pour votre patience.

Jc.

Darkangel · 14-12-2013 20:19:49

Je vous remercie à mon tour pour votre aide.
Entre temps je ne chaume pas, je me forme un peu plus sur le php orienté objet, sur la modélisation MVC etc, ce progresse mais c'est pas simple non plus... Je regarde des vidéos de grafikart. Mais en connaissez vous d'autres par ailleurs afin que je puisse m'améliorer encore?

Jc · 28-12-2013 12:40:08

Bonjour,

Tout d'abord, votre modèle contient beaucoup de redondances. Donc, avant de prendre la décision initiale de dénormaliser - qui peut être lourd de conséquences - il est sage de normaliser correctement votre modèle en premier lieu.

1) En ce qui concerne vos règles de gestion

1) Un établissement à plusieurs utilisateurs et un utilisateur peut faire partie de plusieurs établissement donc sommes nous bien d'accord qu'une table associative s'impose? ce que j'ai fais me semble ici logique. Néanmoins, question: Pourrais-je au sein de cette table associative indiquer les niveaux d'accès ou est-ce préférable de procéder autrement?

Il est prématuré à ce stade de dire ce qui s'impose sur ce seul critère. En effet d'après votre schéma, vous avez plusieurs types de personnes : ceux que vous avez appelés "utilisateurs", ensuite les administrateurs de projet, les personnes ayant l'attribut "judiciaire" (les contacts juridiques? ), un responsable scientifique je suppose et le représentant légal d'un établissement. Peut-être également le wp_leader de l'entité projet_wp représente-t-il une personne également?
Ensuite un représentant légal peut-il être aussi responsable scientifique d'un projet ou contact juridique, ou tout à la fois?
Qu'en est-il des personnes qui seront habilitées à consulter ces informations? les avez-vous oubliées? Merci donc de nous préciser l'ensemble des règles de gestion de l'ensemble des personnes vis-à-vis des entités de votre modèle.

En ce qui concerne les coordonnées de ces personnes, dans un contexte où un administrateur peut être doté d'une autre qualité dans votre modèle comme responsable scientifique par exemple, peuvent-elles avoir un numéro de téléphone ou autre, spécifique à chacune de ces qualités?
Pour terminer sur ce point, devez-vous gérer un historique des représentants légaux d'un établissement ou des personnes travaillant sur un ou plusieurs projets?

Pour finir avec cette partie, qu'en est-il des historiques éventuels à propos des modifications/ajouts/suppressions des utilisateurs sur les différentes composantes d'un projet?

2) Un établissement n'a pas plusieurs données financières donc par conclusion il s'agit d'une relation 1:1. est ce ok?

Cela semble en effet "ok", mais êtes-vous certain de la pertinence de la présence de ces informations au sein de votre modèle vu qu'elles n'interviennent nulle part au sein de votre "sous-modèle" projets? Si une telle relation entre un établissement et les projets qui lui sont associés doit exister en l'état futur de votre modèle, un établissement en l'état actuel des choses ne peut changer de données financières sans impacter l'intégrité référentielle au niveau projet.
Merci de nous éclairer sur ce point donc.

Suite bientôt^^

Darkangel · 06-01-2014 11:50:36

Bonjour JC,

Merci pour votre retour et tous mes voeux pour 2014.

Au sujet des règles de gestion:

en effet un utilisateur à un login et un mot de passe qui lui permettrons d'accéder à l'interface de gestion. (administrateur de certaines catégories ou simplement autorisé à consulter certaines parties)
Une fois connecté, le système ira vérifier le niveau d'accès de ce même utilisateur.

pour chaque projet doit être indiqué un contact:
=> scientifique
=> juridique
=> administratif

le wp leader représente ici à la fois une personne et un etab.
Concrètement, le wp leader représente ici l'établissement en charge de ce WP. mais il est vrai que derrière ce sera le responsable scientifique de ce même établissement qui sera en charge de cela. mais dans tous les cas j'ai besoin de savoir prioritairement l’établissement en charge.

chaque établissement à un ou plusieurs représentants légaux.
ce représentant peut effectivement être un des contacts soit admin/ scientifique ou juridique mais cela est rare..
ceci étant dit, dans le cas du tpe, une même personne peux avoir toutes les casquettes.

effectivement il serait bon d'avoir un historique des représentants légaux car admettons d'un directeur change en cours il est judicieux d'avoir le nom de l’ancien représentant mais aussi le nouveau

pour finir sur la partie historiques des utilisateurs sur les composantes projets:
j'aimerai effectivement mais je n'y avait pas pensé pouvoir garder un historique des personnes impliquées sur un projet même si une personne le quitte pour une raison ou une autre (changement d’établissement / arrêt de la recherche / abandon etc...)

Concernant les données financières.
votre remarque est pertinente car si un établissement changeait de données bancaires à un moment ou un a un autre cela modifierait leurs données y compris pour les projets plus anciens.
Ceci étant, un etab ne change pas de donnée bancaires trop fréquemment non plus donc faut il tout de même prévoir des données bancaires pour chaque projet?

Merci pour votre aide,
Cordialement,

Jc · 06-01-2014 19:42:36

Bonjour,

Meilleurs vœux également

Je pense qu'avant d'aller plus loin sur le reste des points que je souhaitais aborder avec vous, il est important de statuer sur le contenu de votre dernière réponse. Un MCD se doit d'être déplié au maximum pour être pertinent et rester conforme à l'ensemble de vos règles de gestion et spécificités métiers.
A ce titre, il reste du travail concernant déjà la partie utilisateurs.

....
(administrateur de certaines catégories ou simplement autorisé à consulter certaines parties)
....

- Quel est le découpage fonctionnel de ces catégories?
- Quel est la segmentation des parties pouvant être consultées?

Une fois connecté, le système ira vérifier le niveau d'accès de ce même utilisateur.

- Quels sont ces niveaux d'accès? quel sont leur étendue et leur granularité de gestion?

- Peut-il y avoir d'autres types d'utilisateurs que ceux que vous avez déjà cités?
- Si oui qui sont-ils et quelles sont leur prérogatives sur la plateforme? et peuvent-ils jouer un rôle d'intervenant dans vos projets où sont-ils de simples spectateurs vis-à-vis de ces mêmes projets? (lecture seule)

pour finir sur la partie historiques des utilisateurs sur les composantes projets:
j'aimerai effectivement mais je n'y avait pas pensé pouvoir garder un historique des personnes impliquées sur un projet même si une personne le quitte pour une raison ou une autre (changement d’établissement / arrêt de la recherche / abandon etc...)

Désirez-vous allez plus loin dans cette démarche et historiser chaque action effectuée sur un projet donné et un utilisateur donné?

A bientôt de vous lire.

Darkangel · 07-01-2014 09:57:08

Bonjour JC,

Je ne pensais pas qu’il fallait être aussi précis dès le début.

Ne peut-on pas créer de nouveaux niveaux d’accès dans le futur et créer des limites d’accès propre au niveau ?

Dans mon idée je pensais créer la structure générale, les catégories et applications propres à celle-ci et ensuite configurer dans une table de gestion d’accès quel groupe aurait accès à quoi en tant que lecture simple ou lecture/écriture. Mais peut être est ce que je fais fausse route.

- Quel est le découpage fonctionnel de ces catégories?

Je ne suis pas bien sûr de comprendre la question. Souhaitez-vous savoir les catégories à créer ?

Pour le reste des réponses, je vais cogiter un peu plus et revenir vers vous.
Cordialement

Jc · 07-01-2014 11:47:00

Bonjour,

1) Je ne pensais pas qu’il fallait être aussi précis dès le début.
2) Ne peut-on pas créer de nouveaux niveaux d’accès dans le futur et créer des limites d’accès propre au niveau ?

Pour répondre à votre première remarque, en fait il faut l'être suffisamment pour s'assurer de l'invariance du modèle au moins à moyen terme.
Pour vous aider à mieux comprendre, prenons le cas où vous définissez un modèle de données qui n'accepte qu'une seule adresse pour une entité E et que plus tard vous savez que vous aurez besoin de gérer un historique d'adresse pour l'entité E. Si vous ne prévoyez pas cette évolution connue dès le départ dans votre modèle, lorsque vous allez le modifier, il va vous falloir :
1) Modifier votre modèle de données, et migrer vos données du premier modèle vers le second
2) vous assurer que cette migration à préservé la cohérence et la qualité de vos données
3) modifier la couche d'accès métier à votre base de données de votre applicatif (reprendre la majeure partie du code déjà développé qui y est associé).

Alors que si vous aviez dès le départ défini votre modèle en conséquence, le jour où vous commencez à rajouter des adresses, le code existant est déjà capable de le prendre en compte d'une manière transparente. Vous aurez au pire à créer un code supplémentaire pour consulter / gérer cet historique sans modification aucune de l'existant.

Dit en d'autres termes dans le premier cas de figure vous multipliez par 2 ou 3 vos coûts initiaux de développement à terme inutilement, et vu la conjoncture actuelle, il vaut mieux éviter, enfin me semble-t-il.

Pour la 2e question, oui on peut mais dans le contexte évoqué précédemment.

Après il est clair que l'on ne peut pas tout prévoir à l'avance, et il existe des techniques de modélisation qui permettent d'étendre un modèle initial sans en modifier les règles de gestion, mais cela dépends de la nature et du contexte de cette extension.

En ce qui concerne les catégories, quand je parle de leur découpage fonctionnel, je parle de leur spécificité de gestion / d'accès éventuels au sein du modèle.

++

Dernière modification par Jc (07-01-2014 11:50:27)

Darkangel · 07-01-2014 16:42:42

Rebonjour,

Je comprends bien la logique de votre réflexion et il va donc me falloir réfléchir un peu plus à l'ensemble alors… je vais préparer cela pour demain !

il faudrait effectivement que je prévois un système de gestion d'historique plus poussé que ce que j'avais initialement prévu.

Mais cela revient donc à créer plusieurs tables pour des mêmes éléments non?

Exemple une entité ayant une adresse A qui déménage en adresse B.
L’adresse B devient donc officielle mais l'adresse A doit être gardée en historique...de même et dans ce même cas, comment procéder pour savoir que pour tel et tel projet c'est telle adresse à tel moment qui était attribuée?

Jc · 07-01-2014 18:47:12

Bonjour

Mais cela revient donc à créer plusieurs tables pour des mêmes éléments non?

C'est souvent le cas en effet bien que votre tournure soit assez vulgarisée et imprécise

L’adresse B devient donc officielle mais l'adresse A doit être gardée en historique...de même et dans ce même cas, comment procéder pour savoir que pour tel et tel projet c'est telle adresse à tel moment qui était attribuée?

Il n'y a rien de difficile là-dedans, mais chaque chose en son temps si vous le voulez bien, commençons par le début, on verra cela en temps utile.

A bientôt de vous lire,

Jc

Dernière modification par Jc (07-01-2014 18:48:14)

Darkangel · 08-01-2014 11:41:41

Bonjour JC,

Voici ma réflexion sur l'interface, les utilisateurs et leurs droits d'accès à ce stade:

Tout d'abord la structure envisagée :
• 1 base de données
• 2 interfaces
=> 1 interface web en php et mysql (avec frontoffice et backofice)
=> 1 interface tablette et mobile (uniquement pour la consultation)

Concernant les utilisateurs et leurs niveaux d'accès:

Pour chaque niveau d’accès que je vais lister ci-après, je souhaiterai 3 modes :

- Un mode lecture simple (mode 1)
- Un mode lecture / écriture (mode 2)
- Un mode lecture /écriture /suppression (mode 3)

Il est bien évident que suivant le niveau d’accès, tel ou tel mode s’imposera.

Un utilisateur qui n’est pas admin pourra bien évidemment avoir plusieurs niveaux d’accès et modes différents sur les différents projets auquel il a accès.(exemple : lecture simple sur tous les projets (hors phase montage) et lecture écriture et peut être suppression sur certains dont ils auront la charge.

Attention, néanmoins un utilisateur peut être admin de plusieurs établissements ou admin d’un établissement et simple gestionnaire projet dans un autre..

Un administrateur global de l’interface

- Accès et gestion du back-office :
=> Ajout d’un nouvel établissement
=> Ajout de nouveaux utilisateurs pour n’importe quel établissement
=> Pourra se connecter au compte de n’importe quel établissement de la base si accord d’un administrateur général de l’établissement en question afin d’apporter une aide si besoin était.
=> Avertissement des maintenances et autres mises à jour
=> Gestion des droits d’accès
=> Autres à définir…

Pour chaque établissement

1) Un ou plusieurs administrateurs d’établissements

Dans ce profil administrateur j'aimerai envisager s’il faut pousser la réflexion les niveaux d'accès suivant

1.1) un niveau d’admin général ayant le pouvoir modifier toutes les infos d’un établissement et d’attribuer / modifier / supprimer les comptes d’utilisateurs des membres de son établissement et les données liés à leurs projets. (mode 3 sur tout)

1.2) un niveau d’ordre uniquement financier pour modifier les déclarations de trésorerie, les données bancaires, les données liées au budget propres aux projets (toutes phases confondues) etc. (mode 3 sur la partie financière uniquement et mode 1 pour le reste)

1.3) un niveau d’ordre administratif pour modifier uniquement les coordonnées légales d’un établissement (adresse, téléphone, etc.) et pouvoir attribuer tel ou tel niveau d’accès aux autres utilisateurs de son établissement (mode 3 sur la partie admin et mode 1 pour le reste)

Pour chaque projet

1) un ou plusieurs comptes de gestionnaires de projet

1.1) niveau d’accès : administratif pour créer / modifier / gérer les données propres à un projet et lié au :
=> montage (déclaration / contrat / montage et suivi budgétaire /amendement / annexe technique (WP / milestones / deliverables ) etc.
=> Au suivi (reporting / modifications des WP/ milestones / deliverables (avec historique modification)/ modification du budget (avec historique modification)
=> Gestion des feuilles de temps, du personnel à déclarer

1.2) niveau d’accès : scientifique pour créer / modifier / gérer les données propres à un projet et lié au contenu scientifique (avec historiques des mis à jours) => mais il s’agit ici plus d’une gestion de fichier + autres fonctionnalités

1.3) niveau d’accès juridique pour gérer les accords de consortium sur le projet et les amendements spécifiques (avec historique modif) => mais il s’agit ici plus d’une gestion de fichier

@+

Jc · 09-01-2014 03:57:39

Bonjour,

Merci pour ce travail, il permet en effet d'y voir plus clair et d'avancer

Tout d'abord quelques remarques/questions/observations d'ordre général
- Etes-vous certain de vouloir refuser la possibilité à un administrateur de se connecter à son interface via une tablette? Est-ce pertinent?
- Quels seraient les droits d'accès par défaut pour tout nouvel utilisateur sur votre plateforme avant attribution spécifique? (quel niveau et mode d'accès)
-

Un administrateur global de l’interface => Pourra se connecter au compte de n’importe quel établissement de la base si accord d’un administrateur général de l’établissement en question afin d’apporter une aide si besoin était.

Cette faculté qu'à un administrateur global de l'interface d'avoir un tel accès à un autre compte administrateur, doit-il être autorisé explicitement à travers votre modèle, ou un simple accord verbal préalable est suffisant? Si on est dans le second cas, pourquoi alors ne pas donner la possibilité à l'administrateur global d'avoir accès à tout et de loguer toutes ses actions effectuées sur la plateforme, en donnant accès en consultation à l'administrateur général d'un établissement à l'ensemble des logs actions associés à son établissement?
- Quel niveau d'administrateur établissement peut permettre d'intervernir sur toute partie d'un projet de cet établissement? Il est en effet important qu'en cas d'absence, congé, maladie, etc... que le supérieur hiérarchique de cet administrateur absent puisse prendre le relai sur ses prérogatives au sein de la plateforme. Si cela n'est pas possible ainsi, quels sont les règles de gestion qui doivent s'appliquer dans ce cas de figure?
- Qu'en est-il des règles de gestion applicables aux mises à jour?

Pour la suite, et avant de modéliser cette partie, il sera important de connaître la granularité des règles de gestion applicables à la gestion d'un projet au sein d'un établissement, afin de ne pas commettre d'erreur dans la modélisation des relations entre les droits d'accès et de gestion et chaque entité de gestion composant un projet.

++

Dernière modification par Jc (09-01-2014 04:11:45)

Darkangel · 09-01-2014 12:19:07

Bonjour JC,

Merci à vous de m'accorder votre aide.
Je vais répondre point par point car je vois que vous êtes quelqu'un de pro dans la démarche.

- Etes-vous certain de vouloir refuser la possibilité à un administrateur de se connecter à son interface via une tablette? Est-ce pertinent?

Il ne me semblait pas avoir dit cela mais la question se pose.
Je ne vois pas inconvénient à ce que tous mes utilisateurs puissent accéder à l'interface via une tablette. seulement je pense que seul un mode de consultation serait adapté afin d’éviter toute mauvaise gestion. Ceci étant dit si un système d'historique est fait pourquoi ne pas tout autoriser apres tout selon les mêmes règles de gestion que citées.

Quels seraient les droits d'accès par défaut pour tout nouvel utilisateur sur votre plateforme avant attribution spécifique? (quel niveau et mode d'accès)

je précise à toutes fins utiles qu'avant d'entrer login / mot passe et avant qu'une vérification soit établie alors aucun accès ne sera autorisé.
les droits d'accès par défaut sera lecture seul sur les projets déjà débutés ou clôtures (non phase draft, non phase montage, non phase négociatio, non phase amendement)

Cette faculté qu'à un administrateur global de l'interface d'avoir un tel accès à un autre compte administrateur

un accord verbal ne sera pas suffisant, je voudrais pouvoir faire en sorte que tel administrateur après négociation orale puisse autoriser l'admin global via un bouton et une confirmation pendant un temps déterminer ou définitif à se connecter à sa propre interface en mode admin afin de pouvoir l'assister au besoin.

Quel niveau d'administrateur établissement peut permettre d'intervernir sur toute partie d'un projet de cet établissement? Il est en effet important qu'en cas d'absence, congé, maladie, etc... que le supérieur hiérarchique de cet administrateur absent puisse prendre le relai sur ses prérogatives au sein de la plateforme. Si cela n'est pas possible ainsi, quels sont les règles de gestion qui doivent s'appliquer dans ce cas de figure?

ce sont les gestionnaires qui interviennent au niveau projet mais les administrateur y ont également accès soit partiellement soit totalement en mode 3..
du fait qu'il y aura plusieurs gestionnaires et plusieurs administrateurs le problème d'absence ne se pose pas d'office

- Qu'en est-il des règles de gestion applicables aux mises à jour?

je ne suis pas sur de bien cerner votre demande.
lors d'une mise à jour incorporer au système, disons une nouvelle fonctionnalité, il faudrait que l'admin global puisse ou non l'appliquer à tout ou partie des établissements inscrits. seul l'admin global via son back-office gérera cela. les nouvelles fonctionnalités apparaîtrons ou non aux interfaces utilisateurs si activées.

Pour la suite, et avant de modéliser cette partie, il sera important de connaître la granularité des règles de gestion applicables à la gestion d'un projet au sein d'un établissement, afin de ne pas commettre d'erreur dans la modélisation des relations entre les droits d'accès et de gestion et chaque entité de gestion composant un projet.

au plaisir de pouvoir répondre si toutefois je saisissais ce à quoi corresponds la granularité des règles de gestion..

@ bientôt

Jc · 10-01-2014 06:37:53

Bonjour,

Je reviens sur vos réponses, car j'ai plusieurs choses importantes à vous dire.

- Concernant ce que vous avez dit à propos d'un administrateur

------------
Cette faculté qu'à un administrateur global de l'interface d'avoir un tel accès à un autre compte administrateur
------------
un accord verbal ne sera pas suffisant, je voudrais pouvoir faire en sorte que tel administrateur après négociation orale puisse autoriser l'admin global via un bouton et une confirmation pendant un temps déterminer ou définitif à se connecter à sa propre interface en mode admin afin de pouvoir l'assister au besoin.

A ce propos, je ne suis pas partisan d'autoriser un compte à accéder à un autre compte, car cela n'est pas très sécuritaire. En effet chaque compte doit pouvoir rester inaliénable au sein d'un système et chaque personne doit pouvoir rester seule responsable et garante de ce qui est fait à partir de son propre compte. Ses identifiants doivent donc rester connus d'elle seule et en est responsable. Les logs actions sont là justement pour pouvoir auditer qui fait quoi comment, où et quand pour permettre aussi une totale transparence du système et de pouvoir identifier éventuellement lorsqu'un compte a été hacké (adresse IP jamais utilisée sur un compte donné, connexion à une heure inhabituelle ou non autorisée, etc...).
Ensuite s'il s'agit qu'un supérieur puisse accéder au compte d'une autre personne pour une assistance quelconque, il existe des outils pour cela (partage d'écran sur Skype, teamviewer, etc...) il est important de ne pas tout mélanger à ce niveau.

-

ce sont les gestionnaires qui interviennent au niveau projet mais les administrateur y ont également accès soit partiellement soit totalement en mode 3..
du fait qu'il y aura plusieurs gestionnaires et plusieurs administrateurs le problème d'absence ne se pose pas d'office

Vous n'avez pas répondu ici à la question qui était

Quel niveau d'administrateur établissement peut permettre d'intervernir sur toute partie d'un projet de cet établissement

Le but de la question étant d'en déduire les règles de gestion appropriées. Merci donc d'y répondre.

- Concernant les règles de gestion des mises à jour, vous n'avez pas compris la question. En effet, il ne s'agissait pas

lors d'une mise à jour incorporer au système, disons une nouvelle fonctionnalité, ...

d'une nouvelle fonctionnalité mais d'une modification d'une donnée ou information relative à un projet et/ou de façon plus générale à toute information relative à une entité de votre modèle applicatif. Pourquoi?
Quand vous avez dit

Pour chaque niveau d’accès que je vais lister ci-après, je souhaiterai 3 modes :
- Un mode lecture simple (mode 1)
- Un mode lecture / écriture (mode 2)
- Un mode lecture /écriture /suppression (mode 3)

il se trouve que le mode écriture se décompose en deux "sous-modes" qui doivent être gérés distinctement l'un de l'autre et qui par conséquent doivent avoir respectivement leur propres règles de gestion, et sont : le mode ajout et le mode modification.
Il est en effet essentiel dans une application collaborative, application qui je le rappelle à pour but de faire qu'une information donnée puisse être lue et modifiée plusieurs fois par jour par une ou plusieurs personnes dans un contexte concurrentiel (deux personnes modifient une information différemment au même moment), avec prise en compte de chaque modification sans perte de données, que l'information accédée et partagée par tous soit toujours à jour (dans sa dernière version disponible).

Concernant la granularité de gestion d'un projet, il s'agit de determiner à quels composants élémentaires d'un projet décide-t-on d'effectuer un contrôle de gestion et donc d'appliquer des règles associées. Je vois que dans votre réponse vous avez déjà introduits de nouvelles notions de gestion d'un projet qui sont les différentes phases à savoir :

phase draft, phase montage, phase négociation , phase amendement

.
Il va y avoir du pain sur la planche à ce niveau, car par définition la gestion de projet constitue un ensemble de processus transverses à l'entreprise qui devront chacune avoir leur règles métier de gestion.

++

Dernière modification par Jc (10-01-2014 09:08:18)

Darkangel · 10-01-2014 12:01:31

Bonjour,

A ce propos, je ne suis pas partisan d'autoriser un compte à accéder à un autre compte, car cela n'est pas très sécuritaire. En effet chaque compte doit pouvoir rester inaliénable au sein d'un système et chaque personne doit pouvoir rester seule responsable et garante de ce qui est fait à partir de son propre compte. Ses identifiants doivent donc rester connus d'elle seule et en est responsable. Les logs actions sont là justement pour pouvoir auditer qui fait quoi comment, où et quand pour permettre aussi une totale transparence du système et de pouvoir identifier éventuellement lorsqu'un compte a été hacké (adresse IP jamais utilisée sur un compte donné, connexion à une heure inhabituelle ou non autorisée, etc...).
Ensuite s'il s'agit qu'un supérieur puisse accéder au compte d'une autre personne pour une assistance quelconque, il existe des outils pour cela (partage d'écran sur Skype, teamviewer, etc...) il est important de ne pas tout mélanger à ce niveau.

C'est effectivement une position qui se défend et que je comprends

quelques explications toutefois car je crois m’être mal exprimé au départ:
je précise qu'ici il ne s'agissait pas d'autoriser un supérieur à accéder au compte d'une autre personne mais qu'un admin d'un établissement (généralement PME car les gros centres ont assez de monde en interne pour gérer) puisse solliciter l'aide de l’administrateur global non de l’établissement mais de l'interface dans son ensemble (il s'agirait en gros d'un helpdesk)

Après, je conviens que cela puisse poser des problèmes sécuritaires alors je vais abandonner cette idée et rajouterai un système d'aide détaillée.

Quel niveau d'administrateur établissement peut permettre d'intervernir sur toute partie d'un projet de cet établissement

Seul l'administrateur général pourra intervenir sur toute les parties de tous les projets.

Pour plus de précisions: les trois types d'administrateurs pourrons intervenir sur tout ou parti d'un projet de cet établissement
Accès total pour l'admin général
Accès aux budget des projets pour l'admin financier
Accès aux parties de gestions admin (contrats / nego etc) pour l'admin administratif

Concernant les règles de gestion des mises à jour, vous n'avez pas compris la question.

je suis désolé de ne pas avoir fournie la réponse escomptée
En espérant que je répondrais plus ici.

Ceci étant dit la réflexion ici m'aura permis d'identifier un nouvel administrateur que je qualifierais d'administrateur consultatif.
Un admin qui aurait à tout mais seulement en mode consultatif / ce même admin pourra bien évidemment être un gestionnaire d'un des projets et donc avoir un mode 2 sur ce projet spécifique;

Dans le cas d'une modification d'une donnée ou information relative à un projet et/ou de façon plus générale à toute information relative à une entité il est bien évidemment question de garder en stockage toutes les mises à jours effectuées.

il faudrait grossièrement parlant une table d'historique des modifications (ancien contenu / nouveau contenu / date de modif / personne ayant effectuée la modif)
seul l'admin général étant en mode 3 pourra supprimer un historique (ancien contenu devenu totalement obsolète ou autre motif).

dans le cas d'une entité:
- admettons un changement d'adresse (il faut garder l'ancienne quelque part ) et intégrer la nouvelle en tant qu'adresse officielle avec quelque part la date de modif
- admettons un changement de personnes représentantes (signataires, directeurs), il faut également garder les anciennes infos et prendre les nouvelles en tant qu'officiel tout en gardant une date de modification
-admettons un changement d'information bancaires (il faut aussi garder un historique des changements)

un admin général pourra ici intervenir sur tout en mode 3
un admin financier ne pourra intervenir que sur les infirmations bancaires en mode 2 et consulter le reste en mode 1
un admin admin ne pourra intervenir que sur les adresses / personnes représentantes en mode 2 et consulter le reste en mode 1

dans le cas d'un projet:
tant le cas d'un contenu rédactionnel il s'agit ici plus d'une gestion documentaire gérer au sein de la base sql via un historique des versions par datage + personne ayant mis à jour le contenu
néanmoins si une modif est effectuée directement dans le systèmes (exemple changement des WP entre la phase draft et montage) il faudrait ici garder un historique des WP anciens + prendre les nouveaux en tant qu'officiels avec date modif et explications.

un admin général pourra toujours tout faire en mode 3
un admin financier pourra ici et en mode 2 créer et modifier les budgets des projets

Concernant la granularité de gestion d'un projet

Dans un premier temps:

je rajoute déjà les autres étapes au projet:
- phase draft,
- phase montage,
- phase négociation ,
- phase en cours,
- phase amendement ,
- phase clôturée (projet étant arrivé à terme)
- phase rejeté (rejet des commission d'évaluation)
- phase abandon (de l’équipe)

premières réflexions:
https://drive.google.com/file/d/0B0Rb6S … sp=sharing

@
bientôt

Dernière modification par Darkangel (13-01-2014 15:12:01)

PHP|Débutant :: Forums

Advertisement

#26 06-12-2013 20:31:56

Re : question sur l'utilisation du for ($i = 0; $i < $result; $i++)

#27 06-12-2013 20:44:55

Re : question sur l'utilisation du for ($i = 0; $i < $result; $i++)

#28 07-12-2013 01:07:48

Re : question sur l'utilisation du for ($i = 0; $i < $result; $i++)

#29 07-12-2013 12:18:08

Re : question sur l'utilisation du for ($i = 0; $i < $result; $i++)

#30 11-12-2013 09:38:29

Re : question sur l'utilisation du for ($i = 0; $i < $result; $i++)

#31 11-12-2013 12:06:24

Re : question sur l'utilisation du for ($i = 0; $i < $result; $i++)

#32 11-12-2013 13:38:14

Re : question sur l'utilisation du for ($i = 0; $i < $result; $i++)

#33 14-12-2013 12:12:09

Re : question sur l'utilisation du for ($i = 0; $i < $result; $i++)

#34 14-12-2013 20:19:49

Re : question sur l'utilisation du for ($i = 0; $i < $result; $i++)

#35 28-12-2013 12:40:08

Re : question sur l'utilisation du for ($i = 0; $i < $result; $i++)

#36 06-01-2014 11:50:36

Re : question sur l'utilisation du for ($i = 0; $i < $result; $i++)

#37 06-01-2014 19:42:36

Re : question sur l'utilisation du for ($i = 0; $i < $result; $i++)

#38 07-01-2014 09:57:08

Re : question sur l'utilisation du for ($i = 0; $i < $result; $i++)

#39 07-01-2014 11:47:00

Re : question sur l'utilisation du for ($i = 0; $i < $result; $i++)

#40 07-01-2014 16:42:42

Re : question sur l'utilisation du for ($i = 0; $i < $result; $i++)

#41 07-01-2014 18:47:12

Re : question sur l'utilisation du for ($i = 0; $i < $result; $i++)

#42 08-01-2014 11:41:41

Re : question sur l'utilisation du for ($i = 0; $i < $result; $i++)

#43 09-01-2014 03:57:39

Re : question sur l'utilisation du for ($i = 0; $i < $result; $i++)

#44 09-01-2014 12:19:07

Re : question sur l'utilisation du for ($i = 0; $i < $result; $i++)

#45 10-01-2014 06:37:53

Re : question sur l'utilisation du for ($i = 0; $i < $result; $i++)

#46 10-01-2014 12:01:31

Re : question sur l'utilisation du for ($i = 0; $i < $result; $i++)

Pied de page des forums