Dyskusja:Tabela (bazy danych)

Z Wikipedii

[edytuj] Komentarz do artykułu (pierwotnie w artykule)

Komentarz, który powinien zostać przeczytany, aby nie brać tego powyżej zbyt dosłownie.

Praktycznie powyższy fragment o kluczach jest w zasadzie prawdą, lecz całe zagadznienie zostało bardzo mocno spłcone. Indeksy bardzo mocno zachaczają o projektowanie baz danych.

Etap projektowania Na tym etapie nie mówi się o kluczach głównych i obcych. Mamy tylko klucze kandydujące proste i złożone. Klucze obce pojawiają się dopiero przy tranformacji modelu logicznego na model fizyczny.

Klucz prosty - jest to klucz składający się tylko z jednej kolumny

Klucz złożony - składa się z kilku kolumn

Na każdy klucz kandydujący nakładamy ograniczenie UNIQUE

Jeżeli istnieje klucz prosty należy starać się go transformować na klucz główny. (Tylko z głową. Oczywiście, że blob też jest kluczem prostym, ale nie wyobrażam sobie w produkcyjnej aplikacji złączeń po blobie) Jeżeli mamy PESEL i aplikację tylko dla polskich klientów to nie powinno się wprowadzać sztucznego klucza głównego.

Jeżeli są tylko klucze złożone, to trzeba dodać sztuczny klucz główny

---

Przenisłem tutaj, bo ma raczej charakter dyskusji. Po pobierznym przjerzeniu nie widzę różnicy między tym co jest artykule, a tym tutaj. W zasdzie nie widzę nawet specjalnych różnic między tym co jest w artykule. Fakt, że nieco uprościłem sprawę, ale nie chciałem wpisywać tu wszystkich zgadnień projektowania baz danych. Jak znajdę opracowanie według którego pisałem sam artykuł, to dodam w źródłach i będzie można podać więcej szczegółów. Nux ^{zostaw notkę} 19:09, 13 cze 2006 (CEST)

---

No tak, Po części masz rację, ale podszedłeś do sprawy zbyt upraszczając. (A ja zbyt emocjonalnie do tego podchodząc...)

Sam też nie miałem zbytniej ochoty wchodzić w projektowanie BD. (Tz. na początku miałem (co widać), ale przemyślełem sprawę i mi nieco przeszło). Ale wróćmy do dyskusji... (Sorki napadło mnie i pewnie będę chciał się na kimś odgryść ;) Padło na Ciebie)

Myślę, że warto by było ustalić jakiś poziom na którym musimy się zatrzymać, żeby nie wejśc zbyt głęboko w zagadnienie projektowanie baz danych. Uważam, że powinniśmy tu jedynie wspomieć o kluczach, a powięcej przekierować na właściwy artykuł. Tak sobie myślę o (na rzie tylko tematy):

- klucze (może bez dzielenia)
- linki do postaci normalnych
- znaczenie normalizacji
- A może by tak etapy projektowania i co się na którym etapie pojawia

Przepraszam, ale mam mieszane uczucia... Zaraz trochę potnę ten artykuł. Przynajmniej na klucze (bazy danych)

Przepraszam nic nie zrobię. Teraz nie ejstm w stanie. Możel epiej od razu usunąc mój komentarz z dziś. Niestety jestam w takim stanie że nic kreatywnego nie wymyślę. Mogę odpowiadać na pytania (Wczoraj miałem egzamin z projektowania rozproszonych baz danych więc jeszcze sporo umiem ;) )

pBT 17:23, 18 cze 2006 (CEST)

[edytuj] O treści artykułu

Komentarz Stoka do uwag Nuxa zamieszczonych w dyskusji Stoka.

Nux: O ile zmianę w tytule przykładu rozumiem jako chęć utrzymania jednej nomenklatury, o tyle skasowania fragmentu o encjach i relacjach nie rozumiem w ogóle.

Stok: A było tak: Pojedyncza tabela może być reprezentacją pewnej encji (np. książek, mieszkań, ludzi), relacji między nimi, albo może stanowić zawartość całej bazy danych.

Informacja jaką niesie to zdanie, po pominięciu żargonu informatycznego brzmi: Tabelea jest częścią, a może też być całą bazą danych – i po co taki zapis?

Niesie też informacje o tym, że tabele mogą też powstać z relacji między encjami, a nie tylko z encji. Sama encja, to natomiast podstawowe pojęcie z zakresu teorii projektowania baz danych. --Nux (dyskusja) 12:41, 17 gru 2006 (CET)

Chciałby by w artykule nie było słów niezrozumiałych dla przecietnego studenta "nieinforamtyki".

Ech... Podobny problem był poruszany na grafach i większość jednak się zgodziła, że musi być podana formalna definicja gdzieś na początku artykułu. Tutaj na samym początku zresztą język jest dosyć luźny, potem wypada wprowadzić pojęcia, o których każdy może przecież doczytać. --Nux (dyskusja) 13:14, 18 gru 2006 (CET)

Nie wiem też co złego było w podkreśleniu, że jest to obiekt teoretyczny? Może słowo "obiekt" nie było tu szczególnie trafione, ale nie mam pomysłu na inne.

Nie chodzi o słowo obiekt ale o teoretyczny. Nie jest to obiekt teoretyczny, tabele fizycznie istnieją, tak jak istnieją dane w nich zawarte.

Tu się trochę źle wyraziłem - miałem na myśli to, że tabele nie istnieją fizycznie jako coś zbliżonego do tabele, ale wręcz jako parę struktur, a mogą nawet znajdować się w paru plikach. Tabela może np. po optymalizacji być zachowana jako drzewo. --Nux (dyskusja) 12:41, 17 gru 2006 (CET)

Sposób przechowywania danych to inny problem.

Dokładnie o to mi chodziło - tabela nie jest obiektem reprezentowanym fizycznie, w sposób jaki podpowiadały by to intuicja. --Nux (dyskusja) 13:14, 18 gru 2006 (CET)

No i wreszcie nie rozumiem zmian przy opisie klucza głównego - z Twoich zmian wynika, że nie może to być pojedyncza kolumna, co przecież nie jest prawdą.

A co powiesz na zdanie takie, mieszkanie jest obiektem składającym się z pojedynczej lub wielu izb? Albo takie: w firmie jest pojedynczy komputer lub jest wiele komputerów?

Może nie brzmiało by to zbyt dobrze w normalnych warunkach, ale formalnie jeśli w informatyce nie określę, że mieszkanie może się składać z jednego pokoju, to będzie znaczyło, że pojedynczy pokój nie będzie mieszkaniem. --Nux (dyskusja) 12:41, 17 gru 2006 (CET)

Informatyka jest wyjątkiem w logice?

Wręcz odwrotnie - język potoczny nie jest logiczny (stąd zresztą problemy z jego interpretacją). --Nux (dyskusja) 13:14, 18 gru 2006 (CET)

Aha i chciałem spytać, bo ze zmian wnioskuję, że jednak nie zrozumiałem - co masz na myśli przez "położenie w zbiorze danych"? Szczerze mówiąc zastanawiałem się nad usunięciem tego fragmentu, bo to chyba nie ma wiele wspólnego z abstrakcyjnym pojęciem jakim jest tabela w bazach danych...

Pojęcie tabela jest tak samo abstrakcyjne jak abstrakcyjne są określenia program, instrukcja, dane. W implementacjach istnieją one rzeczywiście, a nie są tylko abstrakcyjnym modelem.

A przez położenie rozumiem położenie danych w pliku, strumieniu danych. Dane w źródle danych są ułożone po kolei, pierwszy, drugi, trzeci itd. rekord, odczytując dane program „wie” który z kolei rekord odczytał, dzięki temu może wykonać zmiany w źródle danych, dowiązać dane z innej tabeli. Taki system stosuje się w wielu prostych systemach baz danch, w wielu programowanych w językach ogólnego przeznaczenia takich jak C, Pascal i inne, stosowany jest też powszechnie w bazach kartotekowych.

no tak, ale żeby znać pozycję muszę mieć jakiś niezależny indeks, albo długość rekordów musi być stała. Poza tym taki indeks można traktować jako klucz, a jak się uprzeć to nawet pozycję w pliku też. --Nux (dyskusja) 12:41, 17 gru 2006 (CET)

Tak czy siak musi być metoda na odczytanie danch bazy danych i przypisanie ich do tabel, pól i innych srtuktur. Metoda klucza głównego polega na tym, że w rekordzie muszą być dane jednoznacznie identyfikujące rekord, bez względu na umieszczenie tego rekordu w strukturze tabeli. W metodzie bez klucza ważne jest położenie w pliku, ale wówczas przebudowa, odzyskiwanie miejsca po skasowanych rekordach jest utrudniona.

Ale to nie jest istotne. Można przyjąć równie dobrze, że id nie jest w tabeli, bo jest np. tylko w strukturze indeksu (chociaż o ile wiem zazwyczaj jest i tu i tu, ale przecież nie musi być). Na tej samej zasadzie pozycję można traktować identycznie jak id (numeryczne) tylko z krokiem przyrostu równym wielkości rekordu, a nie równym 1. --Nux (dyskusja) 13:14, 18 gru 2006 (CET)

StoK 19:22, 17 gru 2006 (CET)

StoK 08:35, 16 gru 2006 (CET)