İlişkiler ve Normalizasyon

Question

Sevgili dostlar;

Çalıştığım bir uygulamada Servis Hatları var bu hatların belirli müşterileri bir müşterinin bir çok hattı var ama bir hattın birçok müşterisi yok onun için burada işimiz kolay bu ilişki bire çok ilişki oluyor ancak Servis hatlarını müşterilere yani belli merkezlere taşıyan Tedarikçiler var Ayrıca Tedarikçilere bağlı araçlar var bir Tedarikçi birçok Servis Hattını taşıyor ve Bir Servis Hattı birçok Tedarikçi Tarafından taşınıyor Sabah başka bir tedarikçi Akşam seferini başka bir tedarikçi yapabiliyor ayrıca Aynı Tedarikçinin Sabah Seferini başka bir aracı Akşam Seferini başka bir aracı yapabiliyor bu durumda Çoğa çok (Many to Many) ilişki oluyor bu durumda araya JOIN tablo ekleyerek problemi çözüyoruz ama Demo dosyada da göreceğiniz gibi bazı sıkıntılar baş gösterdi Şöyleki Bir Servis Hattını Sabah Seferini ve Akşam Seferini ayrı araç olmak üzere aynı Tedarikçi yaptığı halde Sabah seferini hakedişe işlediğimiz halde Akşam Seferini işleyemiyoruz.Fazla uzatmadan Demo dosyada size bayağı fikir verecektir. Ayrıca burada bu gibi konulara tartışırsak beyin fırtınası olacaktır.Yani demem o ki Veri Modelleme,İlişkiler,gibi

Şimdiden teşekkür eder selam ederim.

http://filemakerturk.com/?qa=blob&qa_blobid=5097337185199215741

Answer 1

Herkese selam ederim;

 

Nuri Hocam; Sizin çalışmanıza benzer bir nakliye firması için çalışma yapmıştım. Veritabanı ve ilişki yapısını gösteren bir pdf dosya ekliyorum. Burada Sofor tablosu sizdeki TEDARIKCILER tablosuna karşılık gelir.

Bir de HAKEDISLER_Detay layout una karşılık gelen  Tasima layout unun görüntüsünü ekliyorum. 

 

Veritabanı İlişki Yapısı

Taşıma bilgilerinin kayıt edildiği Taşıma layout u ekran görüntüsü

 

Pek beyin fırtınası olmadı ama... :) 

Not: Görüntüde yer alan bilgiler her ne kadar gerçek değerler olmasa da bazı alanları kısmen yada tamamen kapatılmıştır.

 

Herkese hayırlı günler dilerim.

Saygılarımla,

Answer 2

HAT_TEDARIKCI tablosunda ilgili hat için 2 kayıt var, direk id_hat alanı ile ilişki kurulduğu için her zaman en üstteki kayıt getiriliyor. En üstteki kayıtta da id_arac alanından ilişkili olan HKD_HKL_HTL_HTD_ARACLAR tablosundan 34 J 1141 plakasını çekmekte.Hakediş yaparken sefer tipini de el ile seçerseniz sefer tipini de HAT_TEDARIKCI tablosundaki ilişkiye eklerseniz problem çözülür gibi. Örnek dosya indir.

 

Bu arada HATLAR tarihli olmalı gibi geldi bana, çünkü hatlarımızdaki araçlar farklı tarihlerde değişiyor gibi.

Kolay gelsin.

Answer 3

Ercan Hocam ve Mehmet hocam cevabınız için çok teşekkür ederim ben dışarıda olduğum için Mehmet hocanın gönderdiği demo dosyayı açamadım inşaallah akşam kontrol edeceğim burada benim yaklaşım anlaşılmıştır herhalde bir servis hattını çalışan tedarikçi ve aracı kaydediliyor seferleri ayrı ayrı tedarikçiler ve araçlar yapıyorsa ayrı ayrı araçlar kaydediliyor bir hattın sabah servisini A tedarikçisi ama Akşam seferini B tedarikçisi yapabiliyor gene aynı şekilde A tedarikçisinin sabah seferini X plakalı aracı akşamını Y plakalı aracı yapabiliyor. Mehmet hocamın tarih koyma fikri de çok güzel yani ufkumuzu açtı Çünkü araçlar değiştiği için hangi tarihte değiştiğini belirtmemiz gerekiyor bir hatta çalışan araç ve tedarikçi belirlenip işlendikten sonra hakedişe gidip taşeron seçip o taşeronun hangi hatlarda aracı varsa seçip hakediş yaptırıyoruz yalnız Burada sizin de gördüğünüz gibi aracı hakediş Detay tabloya kayıt etmiyoruz Yarın raporlarda bir sıkıntı verebilir mi başka bir yaklaşım olarak da hakediş detaya bir havuz olarak düşünerek tedarikçi id we araç id işlemek gerekir mi hatlara hiç Tedarikçi ve Araç kayıtı yapılmayacak Ama önceki yaklaşım bizim kullanış metodumuz için daha uygun yani bir hatta hangi tedarikçi ve hangi araç veya araçlar çalışıyor ise kayıt ediliyor Mehmet hocamın dediği gibi birde tarih alanı koyup değişiklikler takip edilebilsin.Bu tartışmaya devam ettirelim ki bir şeyler öğrenelim kalın sağlıcakla.

Answer 4

Nuri Hocam, dosyanız sanırım Mehmet Hoca'nın müdahalesi ile çalışır hale gelmiştir.Böyle bir çalışmada nasıl bir yapılandırma olurdu şeklinde düşününce;

1- Öncelikle planlama mı yapılıyor yoksa sadece kayıt mı?

2- Planlama ise hangi periyodda yapılıyor? (günlük,haftalık,aylık).

3- Bu tür bir kurguda bence ilk olarak bir "Tarih" tablosu olmalı,içinde sadece bir tarih alanı olabilir.

4- Doğru bir akış şemasında  "Hakediş" tablosuna aslında ihtiyaç yok.

5- "Tarih" tablosuna bağlı mesela "Seferler" adında bir tablo olmalı (Join Table)

6-"Müşteri" tablosuna bağlı "Hatlar" , "Tedarikçi" tablosuna bağlı "Araçlar" tabloları olmalı.

7- "Araçlar" ve "Hatlar" tabloları "Seferler" tablosunda birleşmeli.Bir "Sefer" için gerekli tüm alanlar "Seferler" tablosuna ilgili tablolardan çekilmeli.

8- En baştaki "Tarih" ve "Seferler" tablolarındaki alanların içerdiği veriler mesela "Hakediş" isimli bir layoutta (tablosu "Seferler") raporlama-değerlendirme amaçlı kullanılabilir vs vs...

9- Tüm bunlar sistemi mekanik olarak çalıştırabilmek için,pop-up vesaire amaçlı ek kopya tablolar da olacaktır.

Mümkün olduğunca az ilişki ve tablo sayısı penceresinden düşününce ilk akla gelenleri yazdım,başka akış biçimileri de denenebilir.Ancak zaten yeterince çalışılmış,Mehmet Hoca'nın paylaştığı dosya işinizi çözdüyse hiç kurcalamayın :))

Bahsettiğim yaklaşımın basit bir örneğinin ekran alıntısı.

 

 

Comments

Hocam;
Cevap için teşekkür ederim.Siz TARİH Tablosunu HAKEDİŞ Tablosu olarak SEFERLER Tablosunu da HAKEDİŞKALEMLER Tablosu olarak düşünün aynı kapıya çıkıyor HAKEDİŞ Tablosunda zaten Tarih Fieldi var ayrıca birde Müşteri ID var bununla birlikte Müşterileri gruplandırıp Müşterilerin hatlarını HAKEDİŞKALEMLER e işliyoruz FileMaker de yapılamayacak şey yok gerekirse hepsi tek tabloda bile tutuluyor ancak bu ne kadar Normalizasyon kurallarına uyuyor veri tekrarı olup İlişkisel Veritabanı mantığından ayrılıyormuyuz bunlar önemli.
Selam edeyorum.

http://beltslib.net/veri-tabanlarinda-normalizasyon.html

---

Peki hocam,siz kurallardan sıkça bahsediyorsunuz ya ben de hatırlatmak istedim, bir yazılımcı  algoritma ve akış şeması kurallarına her şeyden daha önce dikkat etmeli anlamında...


Yukarıda eklediğim ekran alıntısının ilişkilerini de altına ekledim,yarım saatte oluşturulan bu veritabanı,tüm ihtiyaçları bir kaç script yardımıyla hatasız karşılıyor.

Mesele hangi tablonun hangi tabloya benzediği olsaydı sorun yoktu.Asıl sorun genişlemeye açık bir mimari tasarlamak.Bunu yapabilmenin yoluda en baştan herşeyi planlamak."Kervan yolda düzülür" anlayışı mutlaka tıkanacaktır ...

Neyse kolay gelsin ...