ugrás a tartalomhoz

Három tábla egyenrangú kapcsolata

foxmulder · 2008. Jan. 19. (Szo), 15.55
Sziasztok!

Van három táblám:

INGATLANOK (id, cím, tulajdonos, ...)
INGATLANRÉSZEK (id, név, ...)
TULAJDONSÁGOK (id, név, ...)

A felhasználó az igényeinek legjobban megfelelő ingatlant keresi a nyilvántartott ingatlanok tulajdonságai között szűrve. Egy tulajdonság lehet pl.: az épület falának anyaga, vagy a padló burkolata. Előbbi az egész ingatlan tulajdonsága, utóbbi viszont ingatlanrészenként (nappali, fürdőszoba stb) más és más lehet (ezért hozom létre az INGATLANRÉSZEK táblát, amelynek egyik rekordja az "egész ingatlan").

A fenti táblák mindegyikének másik kettővel alkotottt páros kapcsolataihoz is rendelehetők attribútumok (az ingatlan itt csak példa, egyik másik kapcsolat ezek közül erőltetett), ezért ezekre a kapcsolótáblákra is szükség van:

INGATLANOK_TULAJDONSÁGOK (id, ingatlan_id, tulajdonság_id, további mezők)
INGATLANRÉSZEK_TULAJDONSÁGOK (id, ingatlanrész_id, tulajdonság_id, további mezők)
INGATLANOK_INGATLANRÉSZEK (id, ingatlanrész_id, ingatlan_id, további mezők)

Az egyes ingatlanok, egyes ingatlanrészeihez rendelt tulajdonságoknak (több is lehet) még nincs értéke, ezért kell egy, a fenti három táblát összekapcsoló kapcsolótábla is.
A kérdés: ha azt feltételezzük, hogy jóval több lesz a tulajdonságok alapján való keresés, mint az adatbevitel, akkor a három táblát összekapcsoló negyediket hogyan hozzam létre, melyik az optimális (vagy nincs jelentősége)?

Így:
INGATLANOK_INGATLANRÉSZEK_TULAJDONSÁGOK (id, ingatlan_ingatlanrész_id, tulajdonság_id, érték)
..vagy így:
INGATLANOK_INGATLANRÉSZEK_TULAJDONSÁGOK (id, ingatlan_id, ingatlanrész_tulajdonság_id, érték)
..vagy így:
INGATLANOK_TULAJDONSÁGOK_INGATLANRÉSZEK (id, ingatlan_tulajdonság_id, ingatlanrész_id, érték)
..vagy netalán így:
INGATLANOK_TULAJDONSÁGOK_INGATLANRÉSZEK (id, ingatlan_id, tulajdonság_id, ingatlanrész_id, érték)
‹ Elsődleges kulcs számossága PHP + MySQL Fatal error: Call to undefined function mysql_connect() in C:\Inetpub\wwwroot\index.php on line 164 ›
 ■
1

Három tábla egyenrangú kapcsolata

vastagl · 2008. Jan. 23. (Sze), 13.05
Nem ez volt ugyan a kérdés, de miért kell ez az egyenrangú kapcsolat, miért nem lennének jók
normalizált relációs táblák, összekapcsoló negyedik tábla nélkül.
2

Ezt meg én nem értem :)

foxmulder · 2008. Jan. 23. (Sze), 17.49
...ezek normalizált relációs táblák akartak lenni. Azért kell a negyedik (kapcsoló-) tábla, hogy egy adott ingatlan (Cica u. 3.) adott ingatlanrészének (fördőszoba) adott tulajdonságához (burkolat) értéket rendelhessünk (csempe). Ez a "negyedik" kapcsolótábla valójában ugye a hetedik, mert van a három alaptáblánk, ezek mindegyike bináris kapcsolatban van a másik kettővel (ez megint három kapcsolótábla mert a kapcsolatok N:M fokúak) és a hetedik, melyen keresztül a három alaptábla kapcsolódik a másik kettőhöz egyszerre (N:M:P kapcsolat). A bináris kapcsolótáblák létjogosultságát az is alátámasztja, hogy önálló attribútumaik is vannak.
3

Egyenrangú?

janoszen · 2008. Jan. 23. (Sze), 17.53
Szerintem, ezek nem egyenrangú táblák. Egy ingatlannak vannak részei... vagy nem jól gondolom?

De egyébként n:m hozzárendelést külső kapcsolótáblával tudsz csinálni, másképp nem.
4

Szerintem

foxmulder · 2008. Jan. 23. (Sze), 18.06
Több ingatlannak van fürdőszobája, de olyan is akad, amelyikben nincs.
5

Egyenrangú ?

vastagl · 2008. Jan. 23. (Sze), 19.03
Szerintem se egyenrangú, de lehet hogy nem értem pontosan a problémádat.
Én erre gondoltam :

INGATLANOK (ingatlan_id, cím, tulajdonos, ...) primar key ingatlan_id
INGATLANRÉSZEK (ingatlan_id,ingatlanresz_id) primary key ingatlan_id,ingatlanresz_id

-----
INGATLANOK_TULAJDONSÁGAI ( ingatlan_id, ingatlan_tulajdonság_id)
primary key - ingatlan_id,ingatlan_tulajdonságok_id
INGATLANRÉSZEK_TULAJDONSÁGAI ( ingatlan_id,ingatlanrész_id,ingatlanrész_tulajdonság_id)
primary key - ingatlan_id,ingatlanrész_id,ingatlanrész_tulajdonság_id

-----
INGATLAN_TULAJDONSÁGOK ( ingatlan_tulajdonság_id, tulajdonság,érték, .....)
primary key - ingatlan_tulajdonság_id
INGATLANRÉSZ_TULAJDONSÁGOK ( ingatlanrész_tulajdonság_id, tulajdonság,érték, .....)
primary key - ingatlanrész_tulajdonság_id


------
Még lehetne tovább menni ÉRTÉKEK(érték_id,érték) , de ingatlannál nem hiszem hogy ennyire variálni kellene.
7

Ingatlanrészek?

foxmulder · 2008. Jan. 23. (Sze), 19.52
Nem így akartad?

INGATLANOK (ingatlan_id, cím, tulajdonos, ...) primar key ingatlan_id
INGATLANRÉSZEK_INGATLANOK (ingatlan_id,ingatlanresz_id) primary key ingatlan_id,ingatlanresz_id
INGATLANRÉSZEK (ingatlanresz_id, egyéb mezők...) primary key ingatlanresz_id

Én úgy látom, hogy az értéket az INGATLANOK_TULAJDONSÁGOK táblába kéne tenni az INGATLAN_TULAJDONSÁGOK helyett, mert egy tulajdonság egy konkrét ingatlannal kapcsolatban vesz fel értéket (a "szobák száma" a Cica u. 3.-ban 5).
8

Ingatlanrészek ?

vastagl · 2008. Jan. 23. (Sze), 20.08
De, ez kimaradt, ez az amit proclub is irt, csak lehagytam :

INGATLANRÉSZ_NEVEK (ingatlanrész_id, ingatlanrész neve)
primary key ingatlanrész_id
9

Ingatlanrészek

vastagl · 2008. Jan. 23. (Sze), 20.25
De te irtad, hogy vannak tulajdonságok, amik az ingatlanra jellemzőek és vannak
amik az ingatlanrészre. Akkor ehhez kell kötödnie az értékeiknek is. Lesznek olyan jellemzők
a szobaszám mellet, mint pl. a fűtés módja, az olyan dolgokról nem beszélve, ha kiderül, hogy az ingatlannak
három tulajdonosa van stb.
Az értékeket persze veheted egy közös halmazból is.


Ha egy ingatlan öszes tulajdonságára és azok értékeira vagy kiváncsi - ingatlan , ingatlanrész -
akkor kicsit bonyolultabb a lekérdezés persze (pl. UNION-nal ).
11

Igaz

foxmulder · 2008. Jan. 23. (Sze), 20.39
Tényleg írtam, de ott (ha tényleg arra a mondatrészre utalsz) csak a mellett akartam ezt érvként felhozni, hogy a tulajdonságok miért nem lehetnek az INGATLANOK mezői. Közben úgy oldottam meg, hogy van egy speciális ingatlanrész, a "teljes ingatlan".
12

Igaz

vastagl · 2008. Jan. 23. (Sze), 21.11
Na igen , jó sok programsort meg lehet már az elején spórólni :-)
Viszont ha jól sejtem, akkor igy lesz olyan azonosítód ami fixen be lesz égetve a
programba, és hát majd három év múlva , ha módosítani kell ......
13

Beégetve?

foxmulder · 2008. Jan. 24. (Cs), 00.53
Csak annyira lesz fixen beleégetve, mint minden más alkotórész ill. minden más adat. Ez is csak egy rekord az ALKOTÓELEMEK táblában.
6

Fürdőszoba

janoszen · 2008. Jan. 23. (Sze), 19.18
Egy ingatlannak vagy van egy jól meghatározott fürdőszobája, vagy nincs. Ha azt szeretnéd jelölni, hogy van neki, de nem érdekel, hogy az egy konkrét fürdőszoba hogy néz ki, akkor létrehozol egy táblát a lehetséges ingatlanrészekkel, egyet az ingatlanokkal és egy kapcsolótáblát a kettő között, amelyikben egy bejegyzés azt jelenti hogy van neki olyan ingatlanrésze a lehetségesek közül.
10

Vallomás

foxmulder · 2008. Jan. 23. (Sze), 20.32
Nem mondtam el a teljes igazságot. Az alapprobléma az ingatlanokkal volt ugyan összefüggésben, de az egyenrangú hármas kapcsolathoz az által jutottam, hogy ki akartam terjeszteni a dolgot arra az alapproblémára, hogy sok dolog közül választunk ki a tulajdonságai alapján egyet. Megadjuk, hogy öt szoba, min. 120 nm, gázfűtés és megkapjuk az ilyen tulajdonságokkal rendelkező ingatlant. De megadhatjuk, hogy automata váltós, max. 4m hosszú, diesel és megkapjuk az ilyen autótípusokat, vagy a virág piros, a levelek összetettek, a szár fás és megkapjuk az ilyen növényeket. Azóta már én is módosítottam a dolgon, az ingatlanos példánál maradva az INGATLANOK_TULAJDONSÁGOK kapcsolótáblának ugyanis nem látom értelmét. A terner kapcsolat megmaradt, de a kapcsolótábla nem ilyen:

INGATLANOK <-> INGATLANRÉSZEK <-> TULAJDONSÁGOK (id, ingatlan_id, ingatlanrész_id, tulajdonság_id, érték)

hanem az egyik biner kapcsolat azonosítóit használva ilyen:

INGATLANOK <-> INGATLANRÉSZEK_TULAJDONSÁGOK(id, ingatlan_id, ingatlanrész_tulajdonság_id)

UI.: Az egyik biner kapcsolat tehát értelmetlen, a másik a terner kapcsolat alapja lesz, a harmadik (a példában az INGATLANOK_INGATLANRÉSZEK) pedig kiolvasható lesz a terner kapcsolatot megvalósító kapcsolótáblából (amelyik INGATLAN-hoz tartozik valamilyen érték egy INGATLANRÉSSZEL kapcsolatban, abban van olyan ingatlanrész.)
14

Vissza a kezdetekhez

janoszen · 2008. Jan. 24. (Cs), 09.40
Akkor menjünk vissza a kezdetekhez. Hogyan tudnád definiálni a három dolog kapcsolatát? 1:n? n:m?
15

Kapcsolatok

foxmulder · 2008. Jan. 24. (Cs), 12.10
Először azt gondoltam, hogy mindegyik M:N kapcsolatban van a másik kettővel, ez három egyedet jelent, plusz három (biner) kapcsolótáblát, plusz egy terner kapcsolatot kifejező kapcsolótáblát (M:N:P). Ezt értettem három tábla egyenrangú kapcsolata alatt és a terner kapcsolatot kifejező kapcsolótábla szerkezete okozott gondot. Azóta rájöttem, hogy a biner kapcsolatok közül az egyiknek nincs értelme, az egyenrangúság tehát ejtve. Minden biner kapcsolat továbbra is M:N (három helyett már csak kettő van), a terner M:N:P.

A szóhasználatom is félrevezető volt, mert némely ternerek valójában binerek :). Ha van három egyedem: EGYIK, MÁSIK és HARMADIK és ezek között (mindegyiknek mindegyikkel) M:N fokú biner kapcsolatok: EGYIKésMÁSIK, EGYIKésHARMADIK és MÁSIKésHARMADIK akkor a mindhárom alapegyedet egyszerre összekapcsoló tábla csak így terner:

EGYIKésMÁSIKésHARMADIK(egyik_id, másik_id, harmadik_id), így például csak biner:

EGYIKésMÁSIKésHARMADIK: (egyik_és_másik_id, harmadik_id)

A fő gondot az okozta, hogy nem tudtam, hogy az egyik biner (és főleg melyik és miért pont az) kapcsolat legyen a "terner" (ekkor valójában ez is biner) alapja, vagy a kapcsolat legyen valóban terner. Most ott tartok, hogy nem három biner kapcsolat közül kell kiválasztani a "terner" kapcsolatban résztvevő egyik felet, hanem csak kettőből (ennyiből meg már sikerül választani) és a valóban terner kapcsolat létjogosultságát is elvetettem.
16

Azért van még itt kérdés

foxmulder · 2008. Jan. 24. (Cs), 13.50
Bár már elindultam az egyik úton, feltennék még egy kérdést. Ha a három alaptábla:

CÉLOBJEKTUMOK
OBJEKTUMRÉSZEK
TULAJDONSÁGOK

Egy tulajdonságértéket csak a fenti három egyed összekapcsolásával nyert csoporthoz lehet rendelni, tehát terner kapcsolat van ezek között, de értelmezhetőek a biner kapcsolatok is. A három lehetséges biner M:N kapcsolat közül a CÉLOBJEKTUMOK-TULAJDONSÁGOKnak nincs értelme, tehát marad kettő:

CÉLOBJEKTUMOK-OBJEKTUMRÉSZEK
OBJEKTUMRÉSZEK-TULAJDONSÁGOK

A három alaptábla kapcsolatát terner kapcsolattal lehet megvalósítani (bár ezt az esetet zárójelbe tenném, csak elvi lehetőség):

OBJEKTUMRÉSZEK <-> TULAJDONSÁGOK <-> CÉLOBJEKTUMOK

vagy a fenti két biner kapcsolótábla egyikéhez rendelem a harmadikat az alaptáblák közül (a kapcsolat itt is M:N):

CÉLOBJEKTUMOK-OBJEKTUMRÉSZEK <-> TULAJDONSÁGOK vagy
OBJEKTUMRÉSZEK-TULAJDONSÁGOK <-> CÉLOBJEKTUMOK

Kétféle fő módon lehet használni ezt az adatbázist:
Az egyik az adatok bevitele, amikor új CÉLOBJEKTUMOKAT hozunk létre (új rekord az OBJEKTUMOK táblában), azokhoz OBJEKTUMRÉSZEKET rendelünk (új rekordok az OBJEKTUMOK-OBJEKTUMRÉSZEK kapcsolótáblában), majd az új OBJEKTUMOK-OBJEKTUMRÉSZEK rekordokhoz TULAJDONSÁGOKAT (és rögtön értékeket is) rendelünk. Ez a műveleti sorrend ezt a sémát sugallja:

OBJEKTUMOK-OBJEKTUMRÉSZEK <-> TULAJDONSÁGOK

A másik használati mód a CÉLOBJEKTUMOK keresése. A felhasználó kiválasztja az OBJEKTUMRÉSZT és értékeket rendel az adott OBJEKTUMRÉSZHEZ tartozó TULAJDONSÁGOKHOZ, hogy eljusson az ilyen tulajdonságokkal rendelkező CÉLOBJEKTUMHOZ. Ez a felhasználási mód a következő szerkezetet sugallaná:

OBJEKTUMRÉSZEK-TULAJDONSÁGOK <-> CÉLOBJEKTUMOK

Ha feltesszük, hogy a keresések száma lényegesen nagyobb lesz, mint az adatbeviteleké, akkor célszerűbb-e az utóbbi szerkezetet választani (gyorsaság, hatékonyság), vagy totál semmi jelentősége?
17

Vissza a kezdetekhez

vastagl · 2008. Jan. 24. (Cs), 13.57
Akkor az alapkérdésre a válasz:

Jó amit irsz, a negyedik táblának ezt választanám:
INGATLANOK_TULAJDONSÁGOK_INGATLANRÉSZEK (id, ingatlan_id, tulajdonság_id, ingatlanrész_id, érték)

Logikailag ez a legjobb, az adatbáziskezelők az elsődleges kulcsokat jól kezelik. Módosítanék a sorrenden, de ezt is csak olvasási, logikai ok miatt tenném:

INGATLANOK_INGATLANRÉSZEK_TULAJDONSÁGOK (ingatlan_id, ingatlanrész_id, tulajdonság_id, érték... )

Az id nem kell, mivel további altulajdonságok nem lesznek.

Fölösleges az
INGATLANRÉSZEK_TULAJDONSÁGOK (id, ingatlanrész_id, tulajdonság_id, további mezők)
tábla, ebben csak azt rögzítenéd, hogy milyen ingatlanrész milyen tulajdonságokat vehet fel.

A tulajdonság nem igy szerepel ahogy írod.
A kapcsolatok:
ingatlan-ingatlanrész 1:n
ingatlanrész - ingatlanrész tulajdonság 1:n
ingatlan-ingatlan tuljdonság 1:n
ingatlan_tulajdonság - ingatlanrész_tulajdonság n:m

A kapcsolótáblával n:m kapcsolatoknál 1:n kapcsolatot hozhatunk létre,
amit te kapcsolótáblának hivsz, az sima tábla összetett kulccsal, itt nincs ilyen.
A kiindulási pontnál hibázol, az ingatlan egyed, az ingatlanrész egyed és most ne lepődj
meg :) a tulajdonság az tulajdonság, nem pedig egyed, röviden.
18

Nem érteni

foxmulder · 2008. Jan. 24. (Cs), 18.48
Az ingatlan-ingatlanrészt azért határoztam meg 1:N helyett M:N-ként, hogy önállóan is tudjam kezelni az ingatlanrészeket. Nem csak a "Cica u. 3. fürdőszobája" összefüggésban képzeltem el egy ingatlanrészt, hanem egy általános "fürdőszobaság" fogalomban gondolkodtam.

Az ingatlan_tulajdonság (és az ingatlanrész_tulajdonság) így néz ki (így értetted, hogy a "tulajdonság az tulajdonság"))?
INGATLAN(RÉSZ)TULAJDONSÁGOK (id, ingatlan(rész)_id, tulajdonságnév, érték)

Ezt a kapcsolatot egyáltalán nem értem:

ingatlan_tulajdonság - ingatlanrész_tulajdonság n:m


UI.: Ja és még valami: nálad az ingatlanok-ingatlantulajdonságok (és az ingatlanrészek-ingatlanrésztulajdonságok) 1:N fokú kapcsolatok. Nálam azért lett M:N, mert például a "fal" ingatlanrésznek és a fürdőszobai "szanitereknek" is lehet "szín" tulajdonságuk és ki akartam küszöbölni az ismétlődést. Most már látom, hogy ez hülyeség, a "színt" mint fogalmat tényleg értelmetlen külön kezelni.

UUI (jan. 27).: a TULAJDONSÁGOK azért lett tábla, mert ha csak attribútum, akkor egy füdőszobához hozzárendelhetnénk a "kovácsjózsi" tulajdonságot (érvényesítő tábla). Ezt Te is említed, de miért veted el?
19

máshogy

sotetbarna · 2008. Jan. 26. (Szo), 23.09
én azt hiszem az egészet máshogyan fognám meg, mert mi van, ha van egy célobjektumod, annak van egy objektumrésze, aztán a kedves megrendelő egy év múlva kitalálja, hogy annak is lennének alobjektumai, szóval bilincsbe zárnád a fejlődési lehetőséget már a tervezés szakaszában.

csinálnék egy fát az objektumoknak és a részeiknek, ezt egy táblában tárolnám (elég sok megvalósítás létezik, attól függően, hogy mennyi adatot akarsz tárolni), és a fa részeihez lehetne a tulajdonságokat csatolni.

a tulajdonságokat típusokba szervezném (a fa elemei is ugyanezt a típust), mert ha pl. egy nappalit vesznek fel, ott mondjuk nem azok a tulajdonságok fontosak, mint a konyhánál, de ezt elsősorban az adatrögzítés könnyítése miatt tenném.

a keresés így a tulajdonságok között is egyszerűsödne (ha mondjuk a nevet is tulajdonságként kezeled)
20

Persze

foxmulder · 2008. Jan. 27. (V), 04.37
..mert mi van, ha van egy célobjektumod, annak van egy objektumrésze, aztán a kedves megrendelő egy év múlva kitalálja, hogy annak is lennének alobjektumai..

Szerintem ezt nem zárja ki sem az M:N, sem az 1:N fokú objektumok_objektumrészek kapcsolat.

..csinálnék egy fát az objektumoknak és a részeiknek, ezt egy táblában tárolnám..

Ezt ki kéne fejtened..
21

Fa

janoszen · 2008. Jan. 27. (V), 10.05
PL:

+telek paraméterei:...
 +épület paraméterei: hány nm, stb
  +fürdőszoba 1 paraméterei: wc csésze mérete, tükör nagysága
  +fürdőszoba 2 paraméterei: wc csésze mérete, tükör nagysága
 +sufni..
  +traktor...


És itt a howto:
http://weblabor.hu/cikkek/hierarchikusadatkezeles1
http://weblabor.hu/cikkek/hierarchikusadatkezeles2
22

Joe Celko

sotetbarna · 2008. Jan. 27. (V), 12.45
Joe Celko írásait érdemes még elolvasni fával kapcsolatos témákban, van erről egy könyve: Trees and Hierarchies in SQL for Smarties
(a http://dev.mysql.com/tech-resources/articles/hierarchical-data.html -en is rá hivatkoznak)
23

Mér' nem fa?

foxmulder · 2008. Jan. 27. (V), 15.28
http://dev.mysql.com/tech-resources/articles/. Itt baromi sok cikk van felsorolva, ember legyen a talpán, aki végignyálazza. Hogy mé' nem lehet ezeket egy hierarchikus faszerkezetben kategóriákba rendezni?! ;)

Köszi a linkeket! Halassy Béla könyvekkel kelek és fekszem :) Pl.: ez.
24

CakePHP

foxmulder · 2008. Jan. 27. (V), 15.46
CakePHP-t használok, az 1.2 már tartalmaz egy TreeBehavior-t, ami segíti a "Modified Preorder Tree Traversal" módszert. Ebbe még nem mentem bele...

Más: talán már túlragozom a dolgot, de lehet, hogy két faszerkezet is van egyszerre (?). Az egyik a lehetséges alkotórészek lehetséges hierarchiája (pl. a "tető" a "sufni" és a "ház" alkotórésze is lehet, de a "mosdókagylóé" nem, vagy a "WC" lehet a "ház", vagy a "fürdőszoba" alkotórésze, de a "hálószobáé" nem, ezek a megszorítások konkrét ingatlan-előfordulástól függetlenül is fennállnak), a másik a konkrét ingatlan-előfordulások alkotórészeinek egyedi hierarchiája (az egyik ingatlan "ház" alkotórésze egy, a másiké két "fürdőszobát" tartalmaz egy "WC"-vel, míg a harmadikban a "ház" tartalmazza a "fürdőszobát" és a "WC"-t, ugyanakkor egyetlen konkrét ingatlannál sem lehet "teteje" a "mosdókagylónak"). Ez utóbbi fa csomópontjaihoz köthetők a konkrét tulajdonságok és tulajdonság-értékek, míg az elsőhöz a lehetséges tulajdonságok (a "szobához" kapcsolható az "alapterület", a "kazán"-hoz nem).

Tehát: hogyan néz ki egy lehetséges alá-fölérendeléseket definiáló tábla és hogyan érvényesítem az így meghatározott megszorításokat a konkrét hierarchia-előfordulásokra nézve (az érvényesítő tábláról nagyjából tudom, hogy mi)?