NOVINKA - Online rekvalifikační kurz Python programátor. Oblíbená a studenty ověřená rekvalifikace - nyní i online.
Hledáme nové posily do ITnetwork týmu. Podívej se na volné pozice a přidej se do nejagilnější firmy na trhu - Více informací.

Diskuze: Návrh DB - Realitní kanceláře

V předchozím kvízu, Online test znalostí SQL a databází, jsme si ověřili nabyté zkušenosti z kurzu.

Aktivity
Avatar
cech26
Člen
Avatar
cech26:5.12.2013 17:23

Zdravím,
chtěl bych se zeptat na váš názor k tomuto návrhu db realitní kanceláře (viz. níže). Jedná se o školní projekt. Hlavně mě zajímá jestli jsem správně navrhl vztahy mezi jednotlivými tabulkami. Popřípadě kdyby jste viděli i jiné chyby, určitě se rád přiučím :).

Popis: DB by měla uchovávat informace o realitních kancelářích. Každá kancelář má své makléře a zaregistrované prodávající (možná by relace měla být přímo s nabídkami místo makléř -> prodavajicí). Makléři se starají o jednotlivé prodávající a jejich nabídky nemovitostí. Když je nabídka prodána, vytvoří se záznam v tabulce Prodané.

Díky moc za jakékoliv připomínky.

 
Odpovědět
5.12.2013 17:23
Avatar
coells
Tvůrce
Avatar
Odpovídá na cech26
coells:5.12.2013 19:35

Vztahy by měly být tak, jak jsem to neuměle nakreslil na obrázek (nemám tu design tool).

  1. realitka má N makléřů, relace 1xN
  2. makléř se stará o N prodávajících, relace 1xN
  3. prodávající vlastní N nemovitostí, relace 1xN
  4. prodávající udělá N nabídek na M nemovitostí (nabídky se časem mohou měnit a vznikat nové nabídky, nemovitost se ale nemění), relace MxN
  5. zájemce vytváří poptávku na základě nabídky
  6. zájemce může udělat N poptávek na M nabídek (poptávka se opět mění časem), relace MxN
  7. prodej proběhl na základě nabídky a poptávky, relace MxN
 
Nahoru Odpovědět
5.12.2013 19:35
Avatar
Silvinios
Tvůrce
Avatar
Odpovídá na cech26
Silvinios:5.12.2013 19:54

Ahoj,
připravil jsem si pro tebe krátkou anketu:

  1. Prodávající a makléř patří vždy do stejné realitní kanceláře?
  2. Může existovat prodávající bez makléře?
  3. Může existovat makléř bez prodávajících?
  4. Může existovat makléř nebo prodávající bez realitní kanceláře?
  5. Nemovitost má pouze jednoho prodávajícího?
  6. Může existovat nemovitost bez prodávajícího?
  7. Může jednu nemovitost prodávat více realitních kanceláří?
  8. Může se o nabídku ucházet více zájemců?
  9. Jak poznám, že nabídka není prodána? Tím, že pro ni neexistuje záznam v tabulce prodané?
  10. Kam zmizel vlastník?

Narážím na to, že je obtížné vytvořit dobrý databázový model, pokud neznám případy užití...

 
Nahoru Odpovědět
5.12.2013 19:54
Avatar
cech26
Člen
Avatar
cech26:5.12.2013 23:22

Díky za návrhy a postřehy abych odpověděl Silvinois tak:
1)ano
2)ne
3)ano
4)ne
5)prodávající ma N nemovitostí a jedna nemovitost patří právě jednomu prodávajícímu
6)ne nemůže
7)ne, jednu nemovitost může prodávat pouze jedna realitní kancelář
8)ano
9)pokud je záznam v tabulce Prodané tak nabídka je prodaná nebo také id_prodane v tabulce Nabídka se nerovná NULL
10)Nevím co přesně myslíš, id nového vlastníka je uchován v položce vlastník v tabulce Prodané a starý vlastník je v podstatě přístupný přes id_nabidky v tabulce Prodané, jelikož nabídka se po prodeji z db nemaže

 
Nahoru Odpovědět
5.12.2013 23:22
Avatar
cech26
Člen
Avatar
Odpovídá na coells
cech26:6.12.2013 12:19

Díky za odpověď, teď jsem se na to díval a dává to větší smysl než to moje. Jenom jsme úplně neporozuměl tomu bodu 7). Jak si to myslel s těmi prodanými?

 
Nahoru Odpovědět
6.12.2013 12:19
Avatar
Jan Vargovský
Tvůrce
Avatar
Odpovídá na cech26
Jan Vargovský:6.12.2013 12:26

Že máš tabulku pro poptáku a další pro nabídku => ty pak udělají třetí (vazební) kde bude ten prodej

 
Nahoru Odpovědět
6.12.2013 12:26
Avatar
coells
Tvůrce
Avatar
Odpovídá na cech26
coells:6.12.2013 12:30

Máš relace:

  • Nabídka->Nemovitost
  • Poptávka->Nabídka

Když se uskuteční prodej, je to na základě nabídky a poptávky, takže prodej není o prodané nemovitosti, ale o uskutečnění vztahu nabídka/poptávka.

Tím pádem je korektní pouze relace:

  • Prodej->Nabídka, Prodej->Poptávka

Z nabídky se dostaneš na nemovitost, tím pádem víš, co bylo prodáno. Na druhou stranu prodaná nemovitost je taková, kde existuje nabídka odkazovaná prodejem.

Všechny prodané nemovitosti (T-SQL):

select *
from Nemovitost as nem inner join
    Nabidka as nab on nem.id = nab.id_nemovitost inner join
    Prodej as prd on nab.id = prd.id_nabidka

Všechny neprodané nemovitosti (T-SQL):

select *
from Nemovitost as nem inner join
    Nabidka as nab on nem.id = nab.id_nemovitost left join
    Prodej as prd on nab.id = prd.id_nabidka
where prd.id is null

Koukám, že jsem výše uvedl relaci MxN, ale je to vlastně nepovinný vztah 1x1.

 
Nahoru Odpovědět
6.12.2013 12:30
Avatar
coells
Tvůrce
Avatar
Odpovídá na cech26
coells:6.12.2013 12:36

Jinak před tvorbou ER modelu se vyplatí mít use-cases v aplikaci, bez nich se navrhuje databáze hodně těžko. Což je důvod, proč se Silvinios ptal na tolik otázek.

Já se na koukal jako na školní projekt a selským rozumem jsem udělal jednoduchý koncept. Reálná databáze by neměla 10 tabulek, ale tak 100. Tam už to bez UC nejde.

ERM pak musí reflektovat funkční vztahy bez přidaných závislostí. Pokud nemáš rozmyšlené use-cases, vždycky dostaneš model, který je redundantní z hlediska funkčních závislostí. Sice existuje proces dekompozice, kterým se to odstraňuje, ale to už je oprava chybného návrhu.

 
Nahoru Odpovědět
6.12.2013 12:36
Avatar
cech26
Člen
Avatar
Odpovídá na coells
cech26:6.12.2013 12:49

Super, díky moc za vysvětlení, právě ta relace MxN u prodeje mě zmátla :). Předělal jsem to podle tvojich rad a teď to vypadá takhle.

 
Nahoru Odpovědět
6.12.2013 12:49
Avatar
coells
Tvůrce
Avatar
Odpovídá na cech26
coells:6.12.2013 13:29

Ještě můžeš zvážit, jestli u tabulek neudělat flag na aktuální platnost.

Obvykle se v databázi drží i kompletní historie všech událostí. Tzn. že pokud se např. prodejce rozhodne změnit nabídku, tak se stará označí jako neplatná (ale fyzicky se nemaže) a vytvoří se nová. Všechny dotazy do databáze pak musí zohledňovat aktuální platnost záznamu, což je pouze jedna podmínka navíc.

 
Nahoru Odpovědět
6.12.2013 13:29
Avatar
coells
Tvůrce
Avatar
Odpovídá na cech26
coells:6.12.2013 13:32

A koukám, že máš různě pojmenované primární klíče ve všech tabulkách. Primární klíč by vždy měl být "id" bez dalšího názvu.

 
Nahoru Odpovědět
6.12.2013 13:32
Avatar
Kit
Tvůrce
Avatar
Odpovídá na coells
Kit:6.12.2013 13:40

Jsou dvě varianty názvu primárního klíče, každá z nich má své opodstatnění:

  • id bez dalšího názvu, jak uvádíš - je to jednoduché a přehledné
  • id_tabulka - umožňuje použití NATURAL JOIN a USING.
Nahoru Odpovědět
6.12.2013 13:40
Vlastnosti objektů by neměly být veřejné. A to ani prostřednictvím getterů/setterů.
Avatar
coells
Tvůrce
Avatar
Odpovídá na Kit
coells:6.12.2013 20:15

Ani jsem nevěděl, že NATURAL JOIN nebo USING existují. Pracuju s T-SQL a tam nic takového není. Také používám starší nástroje a frameworky, kde různé názvy PK způsobují komplikace.

Nicméně, díval jsem se na diskuze a obě konstrukce se odsuzují jako nepředvídatelné a nedoporučuje se použití, což celkem chápu. Také radši používám průnik funkcionality, aby mi dotazy běhaly na MS SQL Serveru i SQLite současně. Ovšem proti gustu žádný dišputát.

 
Nahoru Odpovědět
6.12.2013 20:15
Avatar
Kit
Tvůrce
Avatar
Odpovídá na coells
Kit:6.12.2013 20:22

NATURAL JOIN beru s rezervou, ale USING někdy používám. Zejména pokud mě někdo nutí, abych používal stejné názvy pro PK a FK. Dlouhé názvy bez používání USING nemají valného významu.

Raději mám jako PK prosté "id" a jako FK "tabulka_id".

Nahoru Odpovědět
6.12.2013 20:22
Vlastnosti objektů by neměly být veřejné. A to ani prostřednictvím getterů/setterů.
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 14 zpráv z 14.