[DB Algemeen] Ontwerp vraag

[Verwijderd]

Stel ik heb een tabel met transportverzekeringsinformatie van een bepaalde vracht.

Nu kan dit zowel per boot als per vrachtwagen vervoerd worden.

Nu loop ik in mijn ontwerp eigenlijk een beetje vast op dit punt, want als het per vrachtwagen vervoerd moet worden dient er een veld 'truck number' aanwezig te zijn, whereas het vervoerstype boot is er een veld 'vessel number' en 'container number' aanwezig moet zijn.

Hoe kan ik dit nou eens netjes afvangen binnen mijn tabel structuur.

Ik zat te denken aan de 'hoofdtabel' met bijvoorbeeld algeme vrachtinformatie (amount insured etc), een 2de tabelletje met transporttype welke vervolgens gekoppeld is aan een specifieke truck of vessel tabel. Is dit een beetje de goede richting?

[MAX3400]

Simpel gezegd zou ik gebruik maken van 3 tabellen, zo uit mijn duim...

Vrachtorder
Vervoersmiddel
Lading

Hierdoor kan je een vrachtorder (voor transport van Lading middels Vervoersmiddel) als leidend houden (lijkt me logisch) en constant aanpassen/updaten als er wordt gewisseld van Vervoersmiddel of als er halverwege een traject Lading bij komt of af gaat?

[mithras]

Het ligt eraan in hoeverre je model uitbreidbaar moet zijn en of je dan een n-n relatie mogelijk wil maken.

Sowieso kan je natuurlijk IS NULL velden mogelijk maken, waarbij je een truck_number, vessel_number en container_number hebt en er een of twee (afhankelijk van de situatie) null zijn.

Dan heb je nog de keuze voor bijvoorbeeld een type-integer meegeven: 0 voor vrachtwagen en 1 voor boot, of dat je een tabel types hebt (id+name) en je in je vracht-tabel daarnaar laat verwijzen. Dan kan je namelijk ook nog ooit een vliegtuig toevoegen bijvoorbeeld

[Exception]

Inderdaad wat jij zegt is de beste optie lijkt mij.

Een hoofdtabel, met een kolom 'type', dat aangeeft wat voor soort vervoer het is. Wordt het vervoerd per vrachtwagen, dan kijken in de tabel van de informatie van de vrachtwagen, en bij boot net zo.

Zo kun je later ook meerere vervoerstypes makkelijk toevoegen.

[whoami]

Je kan het doen zoals jij voorstelt.
Een andere manier om het op te lossen kan zijn:
één tabel met daarin alle nodige columns, dus een column 'vessel number' en een column 'truck number'. In het ene geval is vessel number NULL en truck number ingevuld, en in het andere geval vice versa.
Welke nu in jouw geval de beste oplossing is, hangt er vanaf hoeveel 'specifieke' columns je nodig zult hebben.

[Verwijderd]

Een andere manier om het op te lossen kan zijn:
één tabel met daarin alle nodige columns, dus een column 'vessel number' en een column 'truck number'. In het ene geval is vessel number NULL en truck number ingevuld, en in het andere geval vice versa.

Is dit niet een beetje 'lelijk'?

Verder bedankt voor de input tot dusver :-)

[mithras]

Verwijderd schreef op donderdag 13 september 2007 @ 11:12:
[...]

Is dit niet een beetje 'lelijk'?

Verder bedankt voor de input tot dusver :-)

Het ligt eraan in hoeverre er van dit soort afhankelijkheden bestaan. Als boot/auto de enige opties zijn, en er dan nog een veld resp. twee velden ingevuld moeten worden zijn die extra tabellen imho overbodig.

Wil je het echter zo modulair houden dat het later altijd nog kan, moet je dus wel zoiets doen:
load
type
type_specific_info_1
type_specific_info_2
etc

[engelbertus]

ik vind het lelijk. het mooiste is gewoon apparte tabellen voor elk soort vervoer, en bij de vracht verwijzen naar een vervoertype. index of zo er bij , en de tabel voor het vervoertype vind je elke vracht adh van de index terug. etc.
zo kun je eventueel nog meer vrachten in dezelfde container doen, en makkelijk een overzicht maken met welke containers in hetzelfde schip gaan bijv.

[Voutloos]

mithras schreef op donderdag 13 september 2007 @ 11:15:
Wil je het echter zo modulair houden dat het later altijd nog kan, moet je dus wel zoiets doen:
load
type
type_specific_info_1
type_specific_info_2
etc

N kolommen met namen als 'type_specific_info_X' en type varchar(255), dat is pas écht lelijk.
Gebruik een beperkt aantal specifieke kolommen met aansluitend datatype welke null mogen zijn, of ga gewoon voor de mooie oplossing .

[Verwijderd]

Wellicht zal er in de toekomst behalve trucks en vessels nog airplanes aan worden toegevoegd, hoewel dit type verzekering vrij specifiek is voor vervoer over land.

[ Voor 21% gewijzigd door Verwijderd op 13-09-2007 11:24 ]

[__fred__]

Bekijk het eens OO:

Je neemt een klasse verzekering. Hierin stop je de basisproperties van je Verzekering klasse.
Hiervan inherit je twee subclassen. Vrachtautoverzekering en BootContainerVerzekering. De vrachtauto klasse heeft als extra property een verwijzing naar de verzekerde vrachtwagen, en de bootcontainerverzekering heeft als extra property een verwijzing naar de boot en container die verzekerd zijn.

Vervolgens maak je drie tabellen met 1-1 relaties:

Verzekering
-----------------
VerzekeringID (PK Autoincrement)
Ingangsdatum
Einddatum
Whatever

BootContainerVerzekering
-------------------------------------
VerzekeringID (FK unique constraint naar verzekering)
BootID
ContainerID

Vrachtautoverzekering
--------------------------------
VerzekeringId (FK unique constraint naar verzekering)
VrachtautoId

Dit is zo ongeveer de standaardmanier om een inheritance relatie vorm te geven in een DB.

[mithras]

Voutloos schreef op donderdag 13 september 2007 @ 11:24:
[...]
N kolommen met namen als 'type_specific_info_X' en type varchar(255), dat is pas écht lelijk.
Gebruik een beperkt aantal specifieke kolommen met aansluitend datatype welke null mogen zijn, of ga gewoon voor de mooie oplossing .

Dat was ook zeker mijn eerste oplossing hoor

Maar als je dadelijk 10 types vervoer hebt, met elk een eigen 10-tal variabelen, zit je aan 100 velden die null mogen zijn

En ik bedoel met die namen geen kolommen, maar tabellen
Tabel load (id, name, type_id, general_info_here)
Tabel type (id, name, description oid)
Tabel type_truck(id, load_id, truck_number)
Tabel type_boat(id, load_id, vessel_number, container_number)

Maar voor de duidelijkheid, dit heeft niet mijn voorkeur

edit:
^^ zoals hierboven dus

[Voutloos]

mithras schreef op donderdag 13 september 2007 @ 11:29:
Maar als je dadelijk 10 types vervoer hebt, met elk een eigen 10-tal variabelen, zit je aan 100 velden die null mogen zijn

Vandaar 'beperkt aantal'. Maar goed, ik dacht dus dat je een rits algemene velden bedoelde.

[ATS]

Denk wel even na of een verzekering écht alleen gaat over een vervoerstype, of dat dat er ook combinaties mogelijk zijn. Ik kan me zo voorstellen dat een vracht eerst over de weg naar Rotterdam gaat, dan per boot naar NY, en dan weer per vrachtwagen naar de eindbestemming. Of zoiets. Zijn dat losse verzekeringen, of is dat één polis waarin die verschillende benen van het traject gedekt worden?

[NMe]

Waar hoort mijn topic?

PRG>>SEA

[whoami]

engelbertus schreef op donderdag 13 september 2007 @ 11:20:
ik vind het lelijk. het mooiste is gewoon apparte tabellen voor elk soort vervoer, en bij de vracht verwijzen naar een vervoertype. index of zo er bij , en de tabel voor het vervoertype vind je elke vracht adh van de index terug. etc.
zo kun je eventueel nog meer vrachten in dezelfde container doen, en makkelijk een overzicht maken met welke containers in hetzelfde schip gaan bijv.

Tja , dat hangt allemaal af van de situatie. In situatie x is optie 1 beter, is situatie y is optie 2 beter.

[Verwijderd]

Er wordt een certificaat afdragen voor een bepaald (aantal) goed(eren), per vervoerstraject/type.

Dus als er een lading wasmachines van Rotterdam naar Shanghai moet per boot wordt daar het certificaat op gebasseerd. Als het vervolgens van Shanghai naar st. Petersburg vervoerd moet worden per vliegtuig dient daar een nieuw certificaat over te worden opgemaakt.

[whoami]

__fred__ schreef op donderdag 13 september 2007 @ 11:26:
Bekijk het eens OO:

Je neemt een klasse verzekering. Hierin stop je de basisproperties van je Verzekering klasse.
Hiervan inherit je twee subclassen. Vrachtautoverzekering en BootContainerVerzekering. De vrachtauto klasse heeft als extra property een verwijzing naar de verzekerde vrachtwagen, en de bootcontainerverzekering heeft als extra property een verwijzing naar de boot en container die verzekerd zijn.

Vervolgens maak je drie tabellen met 1-1 relaties:

Verzekering
-----------------
VerzekeringID (PK Autoincrement)
Ingangsdatum
Einddatum
Whatever

BootContainerVerzekering
-------------------------------------
VerzekeringID (FK unique constraint naar verzekering)
BootID
ContainerID

Vrachtautoverzekering
--------------------------------
VerzekeringId (FK unique constraint naar verzekering)
VrachtautoId

Dit is zo ongeveer de standaardmanier om een inheritance relatie vorm te geven in een DB.

Wel, het inheritance probleem dat je hebt met je classes (wat hier eigenlijk het geval kan zijn; je hebt een class 'Freight', met daarvan afgeleid een 'LorryFreight' en een 'ShipFreight' bv, kan je op 3 manieren op DB niveau gaan oplossen:

• Table per concrete class -> Een table LorryFreigth en een table ShipFreigtht, waarbij bepaalde velden zowel in LorryFreigth als in ShipFreight bestaan
• Table per class hierarchy -> Eén table Freight met verschillende NULL velden
• Table per subclass -> 3 tabellen: een met de gemeenschappelijke velden en een discriminator, en een table ShipFreight en een table LorryFreight met enkel de specifieke velden

Wat nu het beste is, hangt gewoon van de situatie af. Indien het bv slechts over één veld gaat dat anders is, dan zou ik voor de 'table per class hierarchy' gaan. Het is nogal onzinnig vind ik om 2 tabellen te gaan introduceren die dan eigenlijk (naast de PK en FK) slechts één veld bevatten.
Daarnaast moet je ook rekening houden dat je, in het geval van 'Table Per Subclass' in dit geval zult moeten gaan joinen (2 OUTER JOINS als je met één query alle Freights wilt ophalen), en dat om dat ene specifieke veldje op te halen.

Even een quote uit een boekje:

Table per class hierarchy
Alternatively, an entire class hierarchy could be mapped to a single table. This
table would include columns for all properties of all classes in the hierarchy. The
concrete subclass represented by a particular row is identified by the value of a
type discriminator column. This approach is shown in figure 3.8.
This mapping strategy is a winner in terms of both performance and simplicity.
It’s the best-performing way to represent polymorphism—both polymorphic and
nonpolymorphic queries perform well—and it’s even easy to implement by hand.
Ad hoc reporting is possible without complex joins or unions, and schema evolution
is straightforward.
There is one major problem: Columns for properties declared by subclasses
must be declared to be nullable. If your subclasses each define several non-nullable
properties, the loss of NOT NULL constraints could be a serious problem from the
point of view of data integrity.

Table Per Subclass
The primary advantage of this strategy is that the relational model is completely
normalized. Schema evolution and integrity constraint definition are straightforward.
A polymorphic association to a particular subclass may be represented as a
foreign key pointing to the table of that subclass.

[Niemand_Anders]

Nu wil ik je eigenlijk geen extra zorgen geven, maar hoe komt de vracht bijvoorbeeld bij een boot? Zeker bij vervoer over spoor of water worden gecombineerde transporten gebruikt dus meestal truck en vrachtschip. Per distributie punt kan namelijk het type vervoer veranderen. De vrachtwagen zou ook een pallet naar schiphol kunnen brengen, waarna het met een vliegtuig naar Berlijn wordt gevlogen en een andere vrachtwagen (van de organisatie) de vracht bij de eind bestemming brengt.

Overigens kun je bij vrachtwagen ook 'container nummer' hergebruiken. Bij container vervoer wordt regelmatig een vrachtwagen + aanhanger gebruikt en inmiddels hebben we ook LZV's (verlengde vrachtwagen van max. 25 meter).

Als ik terug denk aan de uiteenlopende eisen van een Route, tracking & tracing applicatie welke wij voor een transport onderneming hebben moeten schrijven staat het zweet alweer op mijn rug.

[Verwijderd]

Het is niet anders dan dat ik zeg, er wordt een certificaat afgedragen voor 1 traject, either per vessel of per truck. Geen addertjes, geen ander geniep.
Zo'n certificaatje ziet er als volgt uit (ehm ruw overgetypt):

Certificate of Insurance No xxxxx/xxx
For account of: naam/adres bedrijf
File number: xxxxx
Amount Insured: $/€/ oid 24.567,-
Say twenty four thousand etc
Goods Insured: Opoefiets 'station'
Deductible: vast bedrag
From: Shanghai, China
To: Rotterdam, Holland
Per: Vessel
Vessel: Titanic II
Container number: abc1234-098
Date of Departure: 12-July-2012

Vessel en Container number worden alléén bij vervoerstype Vessel gebruikt, in geval van truck wordt er alleen een truck number gevraagd.
Meerdere containers is ook mogelijk natuurlijk, 1000 wasmachines passen niet in 1 container, maar dat is niet zo van belang binnen mijn vraagstelling

[ Voor 20% gewijzigd door Verwijderd op 13-09-2007 12:15 ]

[engelbertus]

tja dan is 1 leeg veldje niet echt een probleem volgens mij, en een tabel wel genoeg. de vraag is dan hoe modulair je het wilt. en of je nu al rekening wilt houden met vliegtuigen of meer gespecificeerde info. je weet maar nooit wat ze in vervoer en terrorismeland nog gaan bedenken, qua verzekering, en waar je deze gegevens intern nog aan wilt koppelen, of vandaan wilt halen.

[whoami]

engelbertus schreef op donderdag 13 september 2007 @ 14:17:
tja dan is 1 leeg veldje niet echt een probleem volgens mij, en een tabel wel genoeg. de vraag is dan hoe modulair je het wilt. en of je nu al rekening wilt houden met vliegtuigen of meer gespecificeerde info. je weet maar nooit wat ze in vervoer en terrorismeland nog gaan bedenken, qua verzekering, en waar je deze gegevens intern nog aan wilt koppelen, of vandaan wilt halen.

Hmm, dat is al ver voorop denken -wat niet altijd kwaad kan- maar ook kan leiden tot YAGNI.
Ik zou zeggen: implementeer het nu in één tabel, en later kan je de boel nog altijd omgooien mocht het nodig zijn.

[BikkelZ]

Ga bij het ontleden naar een datamodel nooit uit van wat je wilt laten zien. Net zoals bij applicaties is het ook in databases niet echt wenselijk om puur op visuele opmaak gerichte informatie in de database op te slaan, tenzij het alleen maar informatie gericht op visuele opmaak is.

Je spullen worden getransporteerd door een Voertuig wat een Boot of een Vrachtwagen kan zijn. Dit topic gaat eigenlijk op een zelfde soort probleem in (Persoon is Docent of Leerling), en er worden door verschillende mensen ook verschillende manieren aangeboden om dat soort zaken op te lossen.

Ik zou zeggen dat een Voertuig een Voertuigtype heeft, en ieder voertuig een voertuigaanduiding (naam schip of kenteken, dat kan wat mij betreft allebei). Bedenk jezelf ook dat een container ook achterop een truck gezet wordt. Dus eigenlijk hoef je in dit geval niet met losse tabellen te gaan werken, enkel hoef je het veld 'vessel number' bij een truck 'truck number' te noemen afhankelijk van het voertuigtype_id.

Misschien doe je er wel beter aan om een container een n:1 relatie te geven met de vracht. Er kunnen altijd meer containers tegelijk verscheept worden in de toekomst natuurlijk.

[Verwijderd]

Met meerdere containers houd ik inderdaad rekening, het is vrij stom om te denken dat 10000 wasmachines in 1 container zouden passen.

Misschien doe je er wel beter aan om een container een n:1 relatie te geven met de vracht. Er kunnen altijd meer containers tegelijk verscheept worden in de toekomst natuurlijk.

Hier heb ik dus uiteindelijk voor gekozen :-)

offtopic:
Maar waar het me omging is een juist datamodel toepassen wat een bepaalde conditie reflecteerd, vessel of truck, en hoewel ik, natuurlijk, alle input zeer waardeer begint men toch een beetje te ver af te dwalen met 'what if's e.d.

Het ís een vrij simpele opzet en de opzet zál in deze context ook niet verandert worden, het is een simpele transportgoederenverzekering welke een lading op een drager dekt, gedurende een rit/reis/w\e. En het is dus binnen die context niet eens van belang of er ondertussen van truck naar vessel wordt geswitched, de verzekering is afgesloten voor de truck reis. Verder gaat dit certificaat gewoon niet

Ik hoop dat ik hiermee niet uit de hoogte mee overkom, want dat is niet de bedoeling, ik probeer slechts wat duidelijkheid te verschaffen omtrent mijn vraagstelling.

[engelbertus]

Dat het niet een goed idee is om visuele zaken als uitgangspunt nemen vind ik een goeie post. ik had er niet op gekomen om op die manier uit te beelden wat ik bedoelde, en waarom ik er voor zou kiezen iets in meerdere tabellen te verdelen.

immers zoals jij het nu zou willen wil je eigenlijk slechts een ordner waarin alle certificaten op vrachtnummr oid worden opgeslagen, maar dan zo dat je er ook nog op andere zaken in kunt zoeken.

ik noem dat meestal een ad-hoc oplossing, want je wilt een probleem oplossen mbv de computer, maar gaat vervolgens aan de slag alsof je alleen het bestaande systeem wilt porteren naar digitaal. wat dus ook geen probleem oplost, maar slechts sneller zoeken mogelijk maakt.

op het werk hebben wij ook talloze voorbeelden hiervan. een excelblaadje voor de verlofuren, een word bestand met de vervoerkostenvergoeding, eenexcelblad met de voortgang van de werken, een excelblad met de projectinschrijvingen. allemaal dus los, niet gekoppeld, en ook bijna niet mogelijk om simpel te koppelen. vervangen door een database is het makkelijks, maar er bestaat geen echte animo voor om dat te gaan laten doen. het werkt immers al opde manier waarop het nu gebeurt. met de nodige problemen, en soms het niet kunnen gebruik maken van handige dingen zoals koppelingen en automatisch opzoeken van gegevens over een prject of betalingsgegevens, offertes en facturen.

Als je dan zoeits wilt oplossen moet je er van uit gaan wat je minimaal wilt opslaan, waarbij informatie niet dubbel hoeft te worden opgeslagen, of waarbij velden geen invulling krijgen.

bij een vracht stel je de gegevens in. wat is het hoeveel, gewichtm, volume, pallets, tanks, dozen.
dan een tabel voor het transport. wijze van vervoer, datum tijden bestemming aankomst, en dan voor het hele traject dus auto, boot en vliegtuig en wat al niet meer mogelijk is. voor elk stuk van het transport geef je het transporttype aan, of slechts en transport (sub)id.

aan een bepaald voertuig koppel je vervolgens het transport (sub)id, en een container nummer, of wat daar in de toekomst nog bij kan komen.

uiteindelijk wil je transporten verzekeren, en op zich geen vracht. je krijgt immers per transport een certificaat, en niet per vracht. de transport tabel is dus eigenlijk de belangrijkste.
in die tabel kun je immers de vracht pzoeken.

dat het ophalen en weergeven dan wat lastiger is dan met 1 tabel is misschien waar, maar beperk je je echt tot 1 tabel dan volstaat een excelblad immers al.

of je maakt er een xml database van dan kun ej on the fly alles toevoegen wat je wilt ;-)

[ Voor 6% gewijzigd door engelbertus op 13-09-2007 16:45 ]