Skapa databas

Kanske missat något inlägg men varför vill ett hyrbilsföretag ha bara "en databas"? Vad ska dom använda den till om det inte finns något gränssnitt eller annat sätt att accessa datan?

Har bara snabbläst tråden men min initiala tanke när jag läst första inlägget och gjort min tolkning av förutsättningarna hos leverantör och beställare är att ett verktyg som Microsoft Access förmodligen vore mer lämpligt än att försöka implementera detta i SQL Server (vilket jag tolkade det som används här men kan ha fel).

För att kolla att det fungerar behöver du inte så mycket data i databasen. Det de menar med >500 mätarställningar är att systemet ska vara byggt för att klara av mer än 500 mätarställningar och m du använt min modell så är det inget problem eftersom varje uthyrning innehåller aktuell bils mätarställning då uthyrningen börjar och då den avslutas. Tabellen klarar (teoretiskt) 9223372036854775807 poster (om minnesutrymmet finns) och alltså lika många mätarställningar.

Skriv dem i en editor på egna datorn och kopiera till sqlfiddle för att köra dem.

Kollade lite på dina tabeller och hittade ett fel. Uthyrning.slutdatum ska inte deklareras 'not null' för då måste du in med slutdatum och tid direkt. I en riktig uthyrning väntar man tills kunden lämnar tillbaka bilen. Kanske stämmer varken start- eller slutdatum med bokningen (om det finns en) och slutdatum vet man ju inte förrän bilen kommer tillbaka.

Tittar vidare ikväll.

Den vet inte riktigt hur den ska hantera indata eftersom du har satt 'fnuttar' kring ett heltal. Bättre att vara väldigt explicit och räkna upp kolumnerna, OBS citat-tecken kring kolumner med svenska diakritiska tecken och inga fnuttar kring postnumret:

insert into kund (personnummer, "förnamn", efternamn, adress, postnummer, ort)
values ('890329-7512', 'Jörgen', 'Rizz', 'Hagavägen', 11466, 'Kil')

Tänker nog inte att detta är rätta platsen för att gå i polemik kring petitesser. Jag kommenterade ditt inlägg utan att ha för avsikt att du ska känna dig kränkt.
1.
Jo, jag vet att det finns olika lösningar för olika behov av datalagring och har använt de flesta. Just nu programmerar jag sökalgoritmer för sökning i semistrukturerad och helt ostrukturerad data.

2.
Jo, jag vet att det finns en write-ahead log och att den endast hanterar A och D i ACID-problematiken och att det, även om det räcker en bit, inte täcker in konsistens-problematiken, vilket min kommentar handlade om.

3.
Nej, han frågade om det spelade någon roll vilken databashanterare han valde och om de "följer TYP samma språk".

Så, ledsen om du kände dig kränkt på något sätt av min kommentar. Ska inte upprepas, inte av mig i alla fall.

En liten fundering i sammanhanget med postnummer... nu är detta ju bara en lek-databas och syftet inte är att skapa ett produktionssystem, men jag skulle inte gjort postnummer som ett integer-fält då detta ger problem med kunder från andra länder än Sverige samt( om man nu anpassar DB:n till att hantera andra länder ) att lands-kods-fält hade varit bra att ha.

Skickades från m.sweclockers.com

Jag återanvände de data som @Tryckvagen hade lagt in.
Dessutom korrigerade jag några småsaker och lade till egenskaper i kostnadstabellen.
Jag automatgenererade via ett python-script 99 poster i kostnadstabellen,
lade till kategorier och knyckte kostnader från ett biluthyrningsföretags så de är marknadsmässiga.
Kostnader för uthyrningar beräknade jag med reglerna på samma företag. Alla uthyrningskostnader beräknades utifrån att 100 km per betalat dygn ingår så om
d är antalet påbörjade dagar,
dp är dagspriset,
k är antalet km (mätarställning__slut - mätarställning_start) och slutligen
kp är km-priset för den kategori bilen tillhör blir hyran
d x dp
om kunden kört högst 100 km per påbörjat dygn och
d x dp + kp x (k - d x 100)
om kunden kört mer än 100 km i snitt per påbörjat dygn.

Eftersom kostnader för företaget är autogenererade finns troligen ingen rimlig relation mellan kostnader och inkomster och mest inkomstbringande bil kan mycket väl vara en förlustaffär.
Om ni importerar databas-skriptet till någon annan databashanterare så gå igenom det och ändra autoinkrement-deklarationerna till det som gäller aktuell db-hanterare. I stort sett måste nog alla "bigserial NOT NULL PRIMARY KEY" ändras. Närmaste motsvarighet i MySQL torde vara "BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE".
De som är vana MySQL-användare kan nog hitta en metod i MySQL Workbench, det fungerade för mig men är så länge sen att jag glömt. Posta gärna anvisningar, den som vet hur man gör. PostgreSQL låg åtminstone förr närmare SQL-standarden än MySQL men det kan ha ändrats.

Ska försöka hinna skriva queries under kvällen och förmiddagen i morgon. Det här är kul men jag har en deadline att passa så hjälp från andra med att formulera frågorna i SQL uppskattas.

Nej, sqlfiddle klagar över "> 8000" tecken

Just det, jag lade till telefonnummer också:

select * from telefon where kund_id < 3;

ger

 id |  typ   |   telnr    | landskod | kund_id 
----+--------+------------+----------+---------
  1 | mobil  | 0701234567 | +46      |       1
  2 | hem    | 0311234567 | +46      |       1
  3 | mobil  | 0702234568 | +46      |       2
  4 | arbete | 0193234569 | +46      |       2
(4 rows)

Samma utan outer join

select b.reg_nr, b.mätarställning, m.märke, m.bränsle_typ
from bil b, modell m where b.mätarställning =
(select max(mätarställning) from bil)
and b.model_id = m.id;

 reg_nr | mätarställning | märke | bränsle_typ 
--------+----------------+-------+-------------
 FTE543 |          50103 | volvo | diesel
(1 row)

På w3schools.com finns en sida SQL AUTO INCREMENT a field med instruktioner för hur man gör i några databashanterare, inklusive MySQL.

Missade det här inlägget. Sant att ER-modellering utvecklades av Peter Chen. Det jag menade var IRM-metoden som innehåller mer än bara ER-modellering. Det framgick inte av mitt inlägg och dessutom har du rätt i att det lilla som jag visade upp är en liten del av det Peter Chen introducerade. Egentligen kom ingenting med av det som Lennart utvecklat på IRM-konsult.
Däremot tror jag att Lennart ersatte romberna för sambandsklasser i Chens notation med linjer med en gaffel i "många"-änden. Det blir också snabbt plottrigt med romberna i stora modeller, linjer blir överskådligare.
Lennart (med flera) lade till verktyg som gjorde IRM till en verktygslåda för hela utvecklingen från idé till färdigt system.

Men: Äras den som äras bör. Peter Chen utvecklade ER-modellering.

Lösningsförslag till några frågor.

Man kan skapa vyer genom

create view inkomst as
select b.reg_nr, sum(u.kostnad) as summa
from bil b, uthyrning u
where b.id = u.bil_id group by b.reg_nr;

och

create view utgift as
select b.reg_nr, sum(k.summa) as kostnad
from bil b, kostnad k

och då kan man hitta bilen som kostat minst med vyn utgift:

select * from utgift where kostnad =
(select min(kostnad) from utgift);

 reg_nr | kostnad 
--------+---------
 FTE543 | 5380.00

Man kan hitta bilen som ger största vinsten genom att använda båda vyerna:

select reg_nr, summa - kostnad as vinst
from inkomst natural join utgift
where summa - kostnad =
(select max (summa - kostnad) from
 inkomst natural join utgift);
 
 reg_nr |  vinst  
--------+---------
 FTE543 | 3145.00

Som koll på att man gjort rätt kan man använda båda vyerna så:

select reg_nr, summa as inkomst, kostnad, summa - kostnad as vinst
from inkomst natural join utgift;
 
 reg_nr | inkomst | kostnad |  vinst   
--------+---------+---------+----------
 FTE543 | 8525.00 | 5380.00 |  3145.00
 USB220 | 1697.00 | 7684.00 | -5987.00
 UUZ445 |  401.00 | 6591.00 | -6190.00

Och om man med "kostar minst" menar kostnad för kunden är det ju lätt
utan vyer:

select b.reg_nr, k.dygnspris, k.kilometerpris from
bil b, modell m, kategori k
where b.model_id = m.id and m.kategori_id = k.id
and k.dygnspris = (select min (dygnspris) from kategori);

 reg_nr | dygnspris | kilometerpris 
--------+-----------+---------------
 FTE543 |    299.00 |          2.00

Frågan "Ta ut totalkostnad för en viss bränsletyp över en period" kan besvaras ganska enkelt genom att vara lite finurlig när man skapar en vy för bilar och deras bränsletyp:

create view bilbränsle as select b.id as bil_id, m.bränsle_typ
from bil b, modell m where b.model_id = m.id;

Jag har alltså döpt om bil.id till bil_id, samma namn som används i kostnadstabellen för att referera till bil.id. Då kan jag använda naturlig join för att kombinera mig fram till kostnaden för en viss bränsletyp. Alltså kan jag få svar på den mer explicita frågan "Vad var totalkostnaden för bensin under mars månad 2016?" med SQL-satsen:

select sum(summa) from kostnad natural join bilbränsle
where typ = 'Bränsle' and bränsle_typ = 'bensin'
and datum > '2016-02-29' and datum < '2016-04-01';

   sum   
---------
 6425.00

select typ, sum(summa) as summa
from kostnad
where datum
between '2016-01-20' and '2016-02-01'
group by typ;

Ja men då kan du inte få ut mer info än att det rör sig om bränsle eller inte bränsle. Bensin eller diesel hittar man i modellen.
Med just dessa datum blir det av en slump bara bränsle och inga andra utgifter.