Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Problem z relacjami w mysql
Forum PHP.pl > Forum > Bazy danych > MySQL
benkas
witam!!

Tworzę bazę danych i mam takie tabele:

create table dziecko (
id_dziecko INT NOT NULL AUTO_INCREMENT,
imie VARCHAR (15) NOT NULL,
nazwisko VARCHAR (20) NOT NULL,
data_ur DATE NOT NULL,
PRIMARY KEY (id_dziecko)
);

create table adres (
id_adres INT NOT NULL AUTO_INCREMENT,
ulica VARCHAR (25) NOT NULL,
kod_pocztowy VARCHAR (6) NOT NULL,
miejscowosc VARCHAR (25) NOT NULL,
PRIMARY KEY (id_adres)
);

create table pracownik (
id_pracownik INT NOT NULL AUTO_INCREMENT,
imie VARCHAR (15) NOT NULL,
nazwisko VARCHAR (20) NOT NULL,
PRIMARY KEY (id_pracownik)
);

moje pytanie do was jest takie, a mianowicie jak najlepiej zrobić referencje, czy w tabeli adres dodać rekordy: id_dziecko, id_pracownik. Czy lepiej w tabeli dziecko zrobic rekord id_adres i w tabeli pracownik analogicznie też rekord id_adres.

Jeszcze druga prośba jak już zaproponujecie mi stworzenie referencji to napiszcie mi dokładnie jak napisać. dodam, że męcze sie juz drugi dzień i nie wiem gdzie będzie wygodniej dodac i jak dopisac to w kodzie.

Z góry dziekuje.
KILIUSZKIN
Moim zdaniem baza nie jest za dobrze zbudowana (wydaje mi się, że tabela pracownik powinna być w relacji jeden do wielu z tabelą dziecko), ale niech tam będzie:

Dodałem klucze obce id_adres to tabel: pracownik i dziecko

create table adres (
id_adres INT NOT NULL AUTO_INCREMENT,
ulica VARCHAR (25) NOT NULL,
kod_pocztowy VARCHAR (6) NOT NULL,
miejscowosc VARCHAR (25) NOT NULL,
PRIMARY KEY (id_adres)
);


create table dziecko (
id_dziecko INT NOT NULL AUTO_INCREMENT,
imie VARCHAR (15) NOT NULL,
nazwisko VARCHAR (20) NOT NULL,
data_ur DATE NOT NULL,
id_adres INT NOT NULL,
PRIMARY KEY (id_dziecko),
CONSTRAINT FK_adres1 FOREIGN KEY (id_adres) REFERENCES adres (id_adres)
);

create table pracownik (
id_pracownik INT NOT NULL AUTO_INCREMENT,
imie VARCHAR (15) NOT NULL,
nazwisko VARCHAR (20) NOT NULL,
id_adres INT NOT NULL,
PRIMARY KEY (id_pracownik),
CONSTRAINT FK_adres2 FOREIGN KEY (id_adres) REFERENCES adres (id_adres)
);
benkas
Bardzo dziekuje za odpowiedz, ale zaintrygowało mnie to co napisałeś o tym, ze baza jest źle napisana.

Jak to twoim zdaniem powinno wyglądac poprawnie?questionmark.gif?

Dodam, nie wiem czy to pomoże ale dziecko może być badane przez kilku pracowników i oczywiście pracownik może badać kilka dzieci.

Czyli raczej relacja wiele do wielu (tylko nie wiem jak skonstruować taką relacjie w tych tabelach)questionmark.gifquestionmark.gifquestionmark.gif

Jak tak analizuje to niestety musze się zgodzic ze nie bardzo to wyglada, ale podpowiedzcie jak to poprawić zeby gralo.


W związku z tym doczytałem troche na ten temat i powinienem utworzyć przy tworzeniu tabeli wiele do wielu dwóch relacji jeden-do-wielu z tabelą trzecią np. rejestracją. Tyle teorii a jak wygląda praktyka?

Pozdrawiam!!

..... Chyba udało mi się rozwiązać problem dziękuje za wskazówkę smile.gif.
KILIUSZKIN
Tak, zgadza się.
Stwórz dodatkową tabelę, np.

create table rejestracja (
id_rej INT NOT NULL AUTO_INCREMENT,
id_pracownik INT NOT NULL,
id_dziecko INT NOT NULL,
data_wizyty DATE NOT NULL,
opis VARCHAR(50),
PRIMARY KEY (id_rej),
CONSTRAINT FK_rej1 FOREIGN KEY (id_pracownik) REFERENCES pracownik (id_pracownik),
CONSTRAINT FK_rej2 FOREIGN KEY (id_dziecko) REFERENCES dziecko (id_dziecko)
);
benkas
Ma takie małe dodatkowe pytanie.

Po stworzeniu tabel dzieci i adresu, i zrobieniu w nich relacji,

jak sprawdzić czy relacje istnieją, tzn. wydaje mi się ze aby móc usunąc rekord z tabeli dzieci będe musiał najpierw usunąc rekord z tabeli adres. A tak nie jest. Prosze o pomoc czy to oznacza, że relacja nie istnieje.

Czytałem własnie o usuwaniu kaskadowym i dlatego nasuwa się to pytanie, ponieważ dane z tabeli dzieci usuwają się bez polecenia on delete cascade, tak jakby nie były powiązane z tabelą adres.

Odpiszcie, pozdrawiam!!
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.