Veri modellemesi: Veri yapınızı tasarlama
Verileri uygulamanızla depolarken veya görüntülerken tasarımın önemli bir parçası veri yapısıdır. Verilerin belirli bir uygulamada veya ekranda nasıl kullanılacağının yanı sıra diğerlerinin verileri nasıl kullanacağını düşünün. Kişilerinize, görevlerinize, iş sürecinize ve hedeflerinize başvurmak, hangi verilerin saklanacağını ve bunların nasıl yapılandırılacağını tanımlamanıza yardımcı olur.
İpucu
Access veritabanı için yazılmış olsa da veri tasarımı temelleri hakkındaki bu makalede veri modellemesi ilkeleri genel olarak ele alınmıştır: Veritabanı tasarımı temelleri.
Örnek olarak aşağıdaki gider raporunu ele alalım.
Gider raporunun, çalışan adı ve departman ayrıntılarını içeren ana kısmını görüyorsunuz. Ana kısmın altında, satın alınan her bir öğe için birden fazla açıklama satırı görüyorsunuz. Bunları satır öğeleri olarak adlandıralım. Satır öğeleri, gider raporunun ana kısmından farklı bir yapıya sahiptir. Bu nedenle her gider raporu için birkaç satır öğesi olduğunu söyleyebiliriz.
Bu tür verileri bir veritabanında depolamak için veri yapısını, veritabanı tasarımında modellememiz gerekir.
Bir-çok (1:N) veri yapısı
Bu, önceki örnekte açıklanan veri yapısı türüdür. Gider raporunun ana kısmı, birkaç satır öğesine bağlıdır. (İlişkiyi satır öğeleri bakış açısından da görebilirsiniz: çok satır öğesi bir gider raporu (N: 1).)
Çok-çok (N:N) veri yapısı
Çok-çok veri yapısı özel bir türdür. Bu, birden çok kaydın birden çok başka kayıt kümesiyle ilişkilendirilebildiği durumlar içindir. İş ortakları ağınız iyi bir örnektir. Birlikte çalıştığınız birden çok iş ortağınız (müşteriler ve satıcılar) var ve bu iş ortaklarınız birden çok iş arkadaşınızla çalışıyor.
Veri modellemesi örnekleri
Bir sistemle gerçekleştirilebilecek çeşitli modelleme türleri vardır. Şimdi birkaç örneği gözden geçirelim.
Örnek 1: İzin onayı isteği
Bu basit örnek, iki veri kümesi gösterir. Bunlardan biri çalışan, diğeri izin isteğidir. Her çalışan birden çok istek göndereceğinden bu ilişki bir-çok ilişkisidir, burada "bir" çalışan ve "çok" isteklerdir. Çalışan verileri ve izin isteği verileri, ortak alan olarak çalışan numarası alındığında birbirleriyle ilişkilidir (anahtar olarak da bilinir).
Örnek 2: Satın alma onayı
Burada veri yapısı oldukça karmaşık görünmektedir ancak bu makalenin başında ele alınan gider raporu örneğine çok benzer. Her satıcı veya tedarikçi birden çok satın alma siparişiyle ilişkilendirilir. Her çalışan birden çok satın alma siparişinden sorumludur. Bu nedenle, bu veri kümelerinin her ikisi de bir-çok veri yapısına sahiptir.
Çalışanlar her zaman aynı satıcıyı veya tedarikçiyi kullanamayabileceğinden satıcılar birden çok çalışan tarafından kullanılır ve her çalışan birden çok satıcıyla çalışır. Bu nedenle çalışanlar ve satıcılar arasındaki ilişki çok-çok ilişkisidir.
Örnek 3: Gider raporlama
Not
Belge dili tercihlerinizi bizimle paylaşabilir misiniz? Kısa bir ankete katılın. (lütfen bu anketin İngilizce olduğunu unutmayın)
Anket yaklaşık yedi dakika sürecektir. Kişisel veri toplanmaz (gizlilik bildirimi).