Power Designer AMC - Création de base de données

21 août 2006, 15:14

Salut.

Je viens de faire un schéma de base de données avec Power AMC.
J'ai fais mon MCD et j'ai ensuite généré mon MPD. Tout ce passe bien jusqu'a ce que gérère le fichier de création de la base.
J'ai droit a ces messages d'erreurs et il stope juste après.

Code : Tout sélectionner

Longueur maximale de l'attribut Code de la table.
Longueur maximale de l'attribut Code de la colonne.
Longueur maximale de l'attribut Code de l'index.

Effectivement quand je regarde les noms de mes tables, colonnes et index, ils dépassent les 30 caractères de plus ou moins 10 caractères.
Ils éxistent des contraintes sur la longueur des noms pour les descriptions de la base ?
Pourquoi ai-je autant de caractères, c'est a cause d'un préfixe qui me prend déjà 9 caractères mais il est utile pour moi car je dois pas avoir de noms en communs avec une autres futures base de données que je ne connais pas encore malheureusement.
Je n'ai pas non plus fait de racourci de mes noms pour qu'ils soient parlant mais je peux largement les réduire mais je préfèrerais avoir une réponse à ma première question.
Merci beaucoup d'avance.

21 août 2006, 17:36

En résumé :
1) tu réserves 9 caractères pour une identification de la base
2) tu dépasses les 20 caractères restants d'une dizaine de lettres

20 caractères pour un nom de variable, c'est déjà énorme ("20_caractères_pour_un" fait 21 caractères). Mais bon ...

En Oracle, les noms des colonnes, tables, index, ... sont effectivement limités à 30 caractères et il n'y a (à ma connaissance) aucun moyen de changer cela.

Une piste : tu dis que tu auras d'autres bases de données et que tu utilises un préfixe. Et si au lieu, d'utiliser un préfixe dans le nom, tu utilisais un nom de schéma comme préfixe et que tu rangeais chaque "base" dans un user différent ?

Exemple :
Tu crées un schéma USER1 et tu y crées tes tables actuelles avec des noms très longs (30 caractères).
Plus tard, tu créeras des schémas USER2, USER3, ... et tu y mettras tes tables avec aussi des noms très longs.
Tu accordes les droits de visibilité en écriture et/ou lecture d'un schéma à un autre.
Tu peux alors avoir des requêtes du type

Code : Tout sélectionner

SELECT A.NOM_TRES_LONG, B.AUTRE_NOM_TRES_TRES_LONG
FROM USER1.TABLE_AVEC_UN_NOM_TRES_LONG A,
USER1.TABLE_AVEC_UN_NOM_PAS_COURT B
WHERE ...

21 août 2006, 18:49

Merci pour la réponse.
Pour Sybase ce doit être la même limitation au niveau du nombre de caractères (30).

Par contre je ne pense pas avoir bien compris l'histoire du schéma.
Si je comprend bien ton idée, c'est d'avoir une nouvelle base par utilisateur mais malheureusement je crois que toutes les tables seront dans la même base. Je n'aurais peut être pas le choix.
A voir si c'est réalisable mais c'est sur que le coup du préfixe m'ennui pas mal. Mes requêttes vont devenir un vrai calvaire pour les taper.
Petit exemple :

Code : Tout sélectionner

select nom_super_mega_long1, nom_super_mega_long2, nom_super_mega_long3, nom_super_mega_long4, nom_super_mega_long5, etc from ma_table_avec_un_nom_long;

21 août 2006, 18:54

Autre petit détail, est-ce si grave si je met dans deux tables différentes des noms identiques de champs ?
Dans ma table utilisateurs.nom et client.nom power amc me génère un warning. Pour moi ça ne me pose pas trop de problème car je considère le model correct mais dans mon entourage on préfère ne pas avoir ce warning.
Un avis sur la question m'interesse pas mal.

22 août 2006, 03:25

Autre petit détail, est-ce si grave si je met dans deux tables différentes des noms identiques de champs ?
Dans ma table utilisateurs.nom et client.nom power amc me génère un warning. Pour moi ça ne me pose pas trop de problème car je considère le model correct mais dans mon entourage on préfère ne pas avoir ce warning.
Un avis sur la question m'interesse pas mal.

Le warning n'indique en rien une erreur de conception mais seulement une limitation de powerAMC. Cette règle dans powerAMC sert uniquement a garantir l'unicité des champs.

Ne te formalise pas pour ton warning et concentre toi plutot sur la longueur des tes noms de tables

22 août 2006, 10:20

Oui comme je le disais,

Pour moi ça ne me pose pas trop de problème

. Mais on est pas tous du même avis la où je travail.
Je voulais donc avoir plusieurs avis sur la question.

Tu me donne déjà un bon départ de réponses. Maintenant j'aimerai en savoir plus sur comment mettre en place la solution d'Henri.

Une piste : tu dis que tu auras d'autres bases de données et que tu utilises un préfixe. Et si au lieu, d'utiliser un préfixe dans le nom, tu utilisais un nom de schéma comme préfixe et que tu rangeais chaque "base" dans un user différent ?

Je ne vois pas trop comment faire une base par projet. En résumé, je vais avoir une base de donnée (la mienne) qui va aller se coupler avec une autre base d'une autre boite. En gros, il faut faire un 'merge' des deux bases pour en obtenir une seule.

Je ne comprend pas trop l'histoire des schémas, si quelqu'un peut me donner plus de détails. Je vais regarder du côté PowerAMC mais aussi du côté de google. Surtout celle de Henri avec des utilisateurs différents.
Autre petit détail, je fais la base pour un mini projet du gros projet définitif. J'ai donc commencer à avoir besoin de tables qui ne font même pas partie de se mini projet directement (c'est plus une histoire de dépendance dans ce cas la).

22 août 2006, 11:53

Je ne sais pas comment ça se passe avec Sybase, mais il n'y a pas de raison que ce soit très différent d'Oracle. Les schémas, ce sont les "utilisateurs" de ta base : le code et le mot de passe qui servent à te logger. Il est possible d'avoir des utilisateurs différents sur une base de données, chacun ayant ses propres tables.

Par défaut, ces tables ne sont visibles que par l'utilisateur connecté : USER1 ne voit que les tables crées par USER1, USER2 celles crées par USER2, ... Mais il est possible par un système de droits que USER1 donne une visibilité en lecture et/ou écriture sur ses propres tables (ordres GRANT).

Concernant le nom de champ unique ou pas : il y a effectivement deux écoles

Code : Tout sélectionner

UTILISATEUR  CLIENT
-----------  ------
ID           ID
NOM          NOM
ou
UTILISATEUR  CLIENT
-----------  ------
ID_UTIL      ID_CLIENT
NOM_UTIL     NOM_CLIENT

Dans le cas d'une jointure clé primaire-clé secondaire, la seconde méthode permet d'avoir un nom de champ identique entre la table fille et la table mère.

Code : Tout sélectionner

CLIENT     FACTURE
------     -------
ID_CLIENT  ID_FACTURE
NOM_CLIENT TTC_FACTURE
           ID_CLIENT

Personnellement, je trouve cette répétition du nom de la table dans les champs lourde et inutile. Je travaille beaucoup avec des requêtes qui se ressemblent et si je n'ai qu'à changer que le nom de la table, c'est quand même vachement plus simple. Par exemple :

function get_geographie ($table) {
$sql = "SELECT A.CODE, B.CODEINSEE, B.LIBELLE
FROM COMPOSITIONTERRITOIRE A, $table B
WHERE A.TERRITOIRE_ID = ?
AND A.CODE = B.CODEINSEE
ORDER BY B.LIBELLE";
...
}

get_geographie ('COMMUNE');
get_geographie ('CANTON');
...

Quant aux clés primaires/secondaires, je préfixe la clé secondaire avec le nom de la table primaire. AMC Designor préfère effectivement quand les deux champs portent le même nom (cela lui permet de faire le lien automatiquement), mais tant pis.

22 août 2006, 13:43

Merci pour l'explication.
Si je comprend bien, un schéma correspond à un utilisateur.
J'ai regarder la documentation de Sybase pour ASE 15 et je trouve deux résultats.
Je peux faire un create table avec ce début de syntaxe :

Code : Tout sélectionner

create table [database.[owner].]table_name ...

et celle ci qui devrait me permettre de créer un schéma mais je me demande si c'est la même chose que pour le create table.

Code : Tout sélectionner

create schema authorization authorization_name create_object_statement ... [permission_statement...]

authorization_name = must be the name of the current user in the database.
create_object_statement = is a create table or create view statement.
permission_statement = is a grant or revoke command.

Est-ce pour vous la même commande pour faire des schémas de tables ? ou pensez-vous que cela peut être différent ?
Je vais faire des tests avec Sybase directement en ligne de commande mais je pose une nouvelle question, comment mettre en place les schémas sous Power AMC ?
J'ai créé un utilisateur et je l'ai appliqué à une de mes tables. J'ai généré le script de création de table et voici le résultat :

Code : Tout sélectionner

create table monuser.service_mon_nom_de_table_long (
  id_service_mon_nom_de_table_long   int identity,
  service_nom   varchar(100) not null,
  service_prenom   varchar(100) not null,
  constraint pk_service_mon_nom_de_table_long primary key nonclustered (id_service_mon_nom_de_table_long)
)
go

Vous en pensez quoi ?

22 août 2006, 14:04

J'utilise PowerDesigner qui doit être le petit frère de Power AMC. Les schémas sont définis au niveau d'une table par le champ Owner qui amène sur une liste de users.

owner = user c'est exactement la même chose sous des vocables différents. En regardant la doc, j'ai l'impression que le schema Sybase est un peu autre chose (alors que sous Oracle, schema = user -- du moins dans l'utilisation que j'en fait).

Ta syntaxe create table monuser.service_mon_nom ... est tout à fait juste. Elle te permet de créer la table :
- soit en étant connecté sous le compte monuser. Dans ce cas l'indication du owner est inutile, mais qu'elle y soit ne pose pas de problème.
- soit en étant connecté sous un compte "superuser" ou "administrator" ou "superadmin" (je ne connais pas le nom du Big Boss sous Sybase)

Regarde du côté du grant

Code : Tout sélectionner

grant select, insert, delete, update
on service_mon_nom_de_table_long 
to user2

22 août 2006, 14:32

Le seul problème que je vois avec la méthode create table c'est que je ne peux pas avoir a priori deux tables communes a deux utilisateurs.

Petit exemple :

Code : Tout sélectionner

create table user1.a (
id_a int primary key,
nom varchar(100) not null
//ICI je voudrais rajouter la contrainte de clé étrangère de la table "c".
)

create table user2.b (
id_b int primary key,
nom varchar(100) not null
//ICI je rajoute la contrainte de clé étrangère de la table "c".
)

create table user2.c (
id_c int primary key,
nom varchar(100) not null
)

Je voudrais que "a" et "b" puissent accéder à "c". C'est d'accord pour user2 puisque c'est lui le schéma de "c". Mais peut-on donner les droits a user1 pour "c" (commande grant je suppose) ?

Je sens que la configuration et l'administration du serveur vas devenir de plus en plus hard.

PS : le super admin sous Sybase c'est 'sa' mais après sous sybase c'est compliqué et pas facile a comprendre. Il faut des roles pour administrer et normallement 'sa' peut tout quasiment tout faire.
Merci pour toutes les explications.

22 août 2006, 15:07

Hummmm..... Je n'avais pas tout bien relu de mon post.
Ma dernière question n'est pas utile et il n'est pas nécessaire de répondre car la réponse est au dessus.

Je vais faire des tests avant de mettre le post en résolu. Je veux être sur que je pourrais faire ce que je veux avec les schémas.
Merci pour toutes vos réponses.

22 août 2006, 15:26

Pour les visibilités entre users, il n'y a pas de problème.

Pour les contraintes d'intégrité de user1.a vers user2.c, il n'y en a pas non plus a priori. La doc Sybase sur CREATE TABLE indique bien

Code : Tout sélectionner

create table [database .[owner ].]table_name (column_name datatype
...
| [constraint constraint_name]
...
|foreign key (column_name [{,column_name}...])
references [[database.]owner.]ref_table    <--------- il y a bien owner
[(ref_column [{, ref_column}...])]

Il faut que le droit de réferencement soit accordé au user1.

Code : Tout sélectionner

grant select, insert, delete, update, references
on c 
to user1

Power Designer AMC - Création de base de données

Qui est en ligne