Witam,

Nie wiem gdzie to umieścić stad pomysł, aby trafiło to na forum związanym z inzynierią oprogramownia. W razie co prosze o info gdzie to umieścić

Jestem samoukiem w MySQL i php. Tworzę bazy danych na wyczucie. Ostatnio postanowiłem że muszę się nauczyc jak sie robi analize projektu. Tak, aby należąc do zespołu ludzi umieć zrobić swój fragment bądz omówić z klientem co i jak i zrobić analize, aby inni wiedzieli czego klient oczekuje.

Z tego co się doczytałem to tu to tam nalezy zrobić analize projektu typu digramy procesów, encji itp.

Jeśli możecie podać mi namiary na jakieś sensowne materiały w sieci gdzie tego szukać. Dodatkowo może znalazłby się ktoś w Warszawie kto odpłatnie wytłumaczyłby łopatologicznie o co chodzi i jak to robic by było dobrze.

Z góry wielkie dzięki za pomoc

Poczytaj o programowaniu XP (np art, na wortalu).

Ja ze swojej strony polecę książkę Java Aplikacje bazodanowe, Najlepsze rozwiązania http://helion.pl/ksiazki/jabnar.htm, w której jest omówiony sposob projektowania relacyjnej bazy danych oraz jej 5 stopni normalizacji. Nie mniej interesującą pozycją jest inna książka o podobnym tytule - Java Aplikacje bazodanowe, wyd. 3 http://helion.pl/ksiazki/javab2.htm

-- edit --
Bardzo dobre narzędzie do projektowania bazy danych to CASE Studio http://www.casestudio.com/. Stworzony projekt możesz wyeksportować do 20 systemów bazodanowych. Dodatkowo można generować raporty w postaci HTML|RTF w których są opisane relacje pomiędzy tabelami. Być może diagramy nie są tak estetyczne jak w DB Designerze, ale za to zgodne ze standardami branżowymi..

Bez normalizacji (sprowadzania do najlepszej postaci) nie da rady. Pamiętaj tylko, że niektórych kwestii nie można znormalizować i często stosuje się denormalizację. Normalizacji jest 5 a nawet i więcej (jest też 333 cech jakie powinine posiadać projekt, ale to już wymysł Pana Boyca Coda). Generalnie sprowadzenie do postaci 3 to już sukces, nie polecam dalszego procesu bo co z tego, że pochwalisz się że masz 4 postać norlaną jak głupi raport z bazy danych będzie wymagał użycia 40 tabel. Podstawą postaci są relacje, ale o tym pewnie wiesz

Odszukaj stron w necie o projektowaniu baz danych, mysle ze cos wygooglasz.
Jak juz bedziesz wiedzial co w trawie piszczy to pod MySQL sciagnij sobie DBDesigner z http://www.fabforce.net/dbdesigner4/, darmowe narzędzie CASE - naprawde wypas. Pamietaj, ze pod MySQL-em relacje to tylko na tabelach InnoDB.

Jak masz jakies pytania pisz na priva.

--
Pozdrawiam,
Andrzej
andopo(at).atn.pl

ok a zatem jest tak:
1) najpierw model EER, czyli rysujesz sobie encje itd., relacje między nimi, czyli realia przenosisz do postaci 'rysunku', modelu coś podobnego do UML (w jednym z podejść UML jest wykorzystywany do modelowania bazy danych), są dwa znane spodoby przedstawiania modelu EER, w necie powinno to być
Za pomocą symblo można przedstawić relacje jeden do jednego itp., oczywiśćie każdy moze sobie sam wymyśłić te symbole ale w pracy zespołowej wykorzystuje się znane modele np. UML
2) model EER przenosimy do schematu relacji, krótko mówiąc
np. mamy tabele 'wyniki' i wygląda to tak:
wyniki(id,data,ocena); ->encja to wyniki(czyli nazwa tabeli) krótko mówiąc w nawiasie wpisujemy nazwy atrybutów(pól) oczywiście możemy również przypisywać NULL i NOT NULL
id-podkreśłone to PRIMARY KEY
falista linia to REFERENCES KEY
może być również klucz References i Primary key razem(przynajmniej tak jest w Oracle w MySql jest to również ale inaczej się implemetuje )
poza tym mogą być klucze 'wielokrotne'
3) tu następuje normalizacja, i tak jak pisano powyzej wystarczą 3, by wszystko było ok, podpowiem tylko, że pierwsza postać to taka, gdzie jest atomowość (rozdzielność) np.
mamy atrybut : Imie i Nazwisko -> nie jest on atomowy
gdy rodzielimy ten atrybut na dwa Imie,Nazwisko to mamy pierwszą postać normalną (to taki prosty przykad) a 2 i 3 postać już do poczytania powiem jedynie że często 1 postać jest też drugą, a drugą trzecią postacią, oczywiśćie to już inna bajka

Każdy kolejny stopień normalizacji bazuje na wcześniejszym. Czyli nie dojdzie się do trzeciego stopnia, gdy tabela nie została doprowadzona do drugiej postaci normalnej.

Dodam tylko ze warto zainteresowac sie scrum.

Możesz zapodać większą ilością informacji / liniem / czymkolwiek?

Siemka, kilka miesiecy temu mialem podbny problem co ty pisalem wtedy magisterke i projekt wiec musialem do tego podejsc w miare profesjonalnie:
wiec tak podam Ci kilka zrodel i maly wstep
jakbys chcial wiecej szczegolow to napisz do lgoral@wp.pl to przesle Ci cos wiecej

1. J. C. Worsley and J. D. Drake. Praktyczny przewodnik PostgreSQL. Helion. 2002, s. 15.

2. L. Banachowski and K. Stencel. Bazy danych. Projektowanie aplikacji na serwerze. EXIT. 2001, s. 133.

3. R. B. Graves. Semantic Modeling in Statistics Canada. Proceedings of ISIS 80 Seminar. VVS. Bratysława
1980. cyt. za Józef Olenski and Witold Staniszkis. Projektowanie bazy danych. 1984, s. 28.

4. J. Olenski and W. Staniszkis. Projektowanie bazy danych. 1984, s. 241.

5 R. K. Stephens and R. Roland. Relacyjne bazy danych. Robomatic. 2003, s. 29-41

6. E.F. Codd. A Relational Model of Data for Large Shared Data Banks. 1970.

7. http://db.tigra-system.pl/art.php?id=11.

8. http://www.ploug.org.pl/seminarium/05 01/pliki/2.pdf,

9. http://www.ia.pw.edu.pl/ttraczyk/bssi/bs1.html.

10. E.F. Codd. Further Normalization of the Data Base Relational Model. In Courant Computer Science Symposium 6: Data Base Systems. Prentice-Hall, 1972.

11. J.D. Ullman and J. Widom. Podstawowy wykład z systemów baz danych. WNT. 2000.

12 . E.F. Codd. Recent Investigation into Relational Data Base Systems. In IFIP Congress. 1974.

13 R. Fagin. Multivalued Dependencies and a New Normal Form for Relational Databases. ACM TODS 2, 1977.

Jest tego jeszcze troszke

Pomimo, iz oferowane mozliwosci baz danych
znacznie sie zwiekszyły w przeciągu ostatnich 30 lat, to proces projektowania schematu bazy ciagle jest taki sam. Głównym
celem tego procesu jest wyspecyfikowanie wymagan uzytkowników przyszłej bazy danych
(dokonanie analizy), a nastepnie utworzenie schematu bazy spełniajacego te wymagania
i jednoczesnie gwarantujacego poprawne funkcjonowanie tej bazy danych.
Powszechnie przyjety sposób projektowania tej czesci każdego systemu , który dotyczy bazy danych składa sie z trzech etapów: pojeciowego, logicznego oraz fizycznego. Kolejnosc tych faz jest scisle okreslona, a pominiecie, którejs z nich moze doprowadzic do niespójnosci poczatkowych wymagan projektowych z koncowa realizacja projektu....

Hej.

Piszesz że należąc do zespołu chcesz zrobić swoje - a jaką rolę w zespole będziesz spełniał(rozumiem, że zespole programistycznym, informatycznym)?

Może to być:

- Analityk
- Projektant
- Programista
- Administrator

Ewentualnie, projektantów można rozbić na podprojektantów... i teraz zastanów się czy chcesz implementować projekty, czy je tworzyć - jeśli tworzyć to jak pisali przedmówcy odnośnie struktur danych(najczęściej baz) używa się narzędzi case do rysowania diagramów związków encji - dobra pozycja moim zdaniem to casestudio(można też modelować dane za pomocą takich języków jak ODL, etc - ale myślę, że nię będzie Ci to potrzebne).

Jednak na tym sprawa się kończy - chyba, że jak to Polsce często bywa musisz przejąć rolę Analityka, Projektanta, Programisty, a później jeszcze dbać o sprawy administracji i utrzymania systemu. Wtedy poleciłbym oprócz specjalistycznych pozycji na temat samych baz danych, jakąś książke odnośnie projektowania systemów informatycznych, zarządzania takimi projektami, dokumentacji ich itd. To nauczy Cię patrzeć z różnych perspektyw na system informatyczne, w tym także aplikacje www, czy strony internetowe. Książek takich jest mnóstwo na rynku, jak materiałów w sieci -> google

pozdrówka

anas