Kategori arasında karar veren Supertype / Subtype: tam ayrık veya eksik çakışma

Masaüstü bilgisayarlar, dizüstü bilgisayarlar, anahtarlar, yönlendiriciler, cep telefonları vb.Gibi BT donanımlarını depolayan bir envanter veritabanı oluşturuyorum. Tüm cihazların tek bir tabloda saklandığı süper tip / alt tip kalıbı ve belirli bilgileri kullanıyorum alt tür tablolara konur. Benim açmazım aşağıdaki iki tasarım arasında seçim yapmak:

Üst diyagramda tüm cihazlar ortak alt türleri paylaşır. Örneğin, masaüstü bilgisayarlarda ve dizüstü bilgisayarlarda aşağıdaki tablolarda kayıtlar bulunur: Aygıt, NetworkDevice. Bir anahtarda şu kayıtlar bulunur: Device, NetworkDevice. Bir yönlendiricinin kayıtları şöyledir: Device, NetworkDevice, WANDevice. Konumunu izlediğimiz tüm cihazların Konum'da bir kaydı olacaktır. Bu kurulum için düşündüğüm bazı artıları ve eksileri:

• Profesyonel: Kayıtları Ana Makine Adı veya LocationID gibi ortak bir alana göre seçmek daha kolaydır.
• Pro: Boş alan yok.
• Con: Belirli bir cihaz için CRUD işlemlerine dahil edilmesi gereken tablolar açık değildir ve gelecekteki DBA'ları karıştırabilir.

Alt şemada tüm cihazların kendi alt türleri vardır (Burada gösterilmeyen daha fazla cihaz sınıfı vardır). Bu durumda, hangi tablo kayıtlarının ekleneceği veya seçileceği açıktır. Masaüstü bilgisayarlar ve dizüstü bilgisayarlar Bilgisayar, vb gidin. Bu kurulum için düşündüğüm bazı artıları ve eksileri:

• Pro: Alt türler için CRUD işlemleri için hangi tabloların kullanılacağı hemen açıktır.
• Pro: CRUD işlemleri için yalnızca bir tablo kullanmanız gerekir.
• Con: Kayıtları ortak alt tür alanlarına göre SEÇMEK için tüm tabloların birleştirilmesi gerekir; örneğin, Hostname veya LocationID ile arama.

Her iki durumda da, ClassDiscriminator alanı, hangi türlerin eklenebileceğini denetlemek için bir CHECK kısıtlamasıyla kullanılmak üzere alt tip tablolara yerleştirilir.

Hangi tasarımın daha iyi olduğuna dair herhangi bir öneri var mı, yoksa tamamen bir fikir meselesi mi ve veritabanının amaçlanan amacına bağlı mı?

EDIT: "NetworkDevice" tablosunun örtüşen doğası ile ilgili bir soru var. Bu tablo, bilgisayar, anahtar veya yönlendirici olsun, ana bilgisayar adı ve / veya IP adresi olan herhangi bir aygıt için ağ bilgilerini tutmak içindir. Bu tablonun örtüşen doğası sorunlara neden olabilecek bir şey mi, yoksa bu şekilde uygulamak uygun mu?

Sağlanan tüm girişler için şimdiden teşekkür ederiz. Lütfen ek bilgi gerekip gerekmediğini sorun.

Veritabanında alt türlerin fiziksel olarak uygulanması karmaşık bir konudur. Zorlayıcı avantajlar sunduğu bir durumunuz yoksa (bir veya iki örnek için aşağıya bakın), nispeten az değer sağlarken uygulamaya karmaşıklık katar.

Bunu gerçekten karmaşık alt tiplerle (mahkeme dava yönetim sistemindeki uygulamalar ve cezalar, farklı kombine riskli ticari sigorta sözleşmesi yapıları) yaptıktan sonra, bu konuda bazı gözlemlerim var. Bazı önemli köşe vakaları:

• Alt türlerdeki veritabanı alanlarının toplam sayısı nispeten düşükse (örneğin: 100'den az) veya alt türler arasında önemli bir ortaklık varsa, alt türleri ayrı fiziksel tablolara ayırmak muhtemelen çok az değer taşır. Raporlama sorgularına ve aramalarına önemli ölçüde ek yük getirecektir. Çoğu durumda, tek bir tabloya sahip olmak ve uygulama içindeki alt türünüzü yönetmek en iyisidir. (Muhtemelen sorununuza en yakın)

• Alt türünüz çok ayrıksa ve farklı alt türlerde, onları asan türe bağlı veri yapıları varsa (örn. Alt tablolar veya daha karmaşık yapılar), o zaman alt tür tablolar anlamlı olur. Bu durumda, her alt tür muhtemelen uygulama içinde nispeten az ortaklığa sahiptir (yani, uygulama içinde muhtemelen bu alt tür için ayrılmış bir alt sistem vardır). Çoğu raporlama ve sorgulama büyük olasılıkla belirli bir alt tür içinde gerçekleşir ve çapraz tür sorgular çoğunlukla birkaç ortak alanla sınırlıdır. (Mahkeme dava yönetim sistemi)

• Farklı özniteliklere sahip çok sayıda alt türünüz varsa ve / veya bunu yapılandırılabilir kılmak için bir gereksiniminiz varsa, genel bir yapı ve ek meta veriler daha uygun olabilir. Olası yaklaşımlar hakkında özet bilgi için bu SO yayınına bakın . (Sigorta poliçesi yönetim sistemi)

• Alt türleriniz arasında çok az ortaklığa ve alt tür tabloları sorgulamak için çok az gereksiniminiz olan çok sayıda alanınız varsa (yani, alt tür tablolarınıza karşı çok yönlü dış birleşimler yolunda çok fazla bir şey yoksa), tür tabloları sütun yayılımını yönetmeye yardımcı olabilir. (Sorununuzun patolojik olarak karmaşık sürümü)

• Bazı O / R haritacıları, alt sınıfları yönetmek için yalnızca belirli bir yaklaşımı destekleyebilir.

Çoğu durumda, bir DB şemasındaki fiziksel alt tür tablolar, potansiyel olarak istenmeyen yan etkilere sahip oldukları için, bir sorunun araştırılmasında biraz çözümdür.

Sizin durumunuzda, nispeten az sayıda alt tipe ve yönetilebilir sayıda özelliğe sahip olduğunuzu varsayıyorum. Diyagramınız ve sorunuz, alt tabloları kayıtlardan asmaya niyetlenmemektedir. Yukarıda önerilen ilk seçenekle devam etmeyi ve bir tabloyu korumayı ve uygulamanızdaki alt yazmayı yönetmeyi düşünmenizi öneririm.

İlk olarak David Hay'ın bir kitabı olan Enterprise Model Patterns'te bulunan veri modelleme sınıflandırma hiyerarşisinin kurallarını kullanarak sağlam bir mantıksal veri modeli geliştirmeyi düşünün . Bir sınıflandırma hiyerarşisi oluştururken, her bir oluşum (satır) bir ve yalnızca bir alt türden olmalıdır. Bu, alt türlerin birbirini dışladığı anlamına gelir. Sınıflandırma, tek, temel, değişmeyen bir karakteristiğe dayanmalıdır. Bu temel kuralı kullanmak, modelinize çok açıklık sağlayacaktır. Sahip olduğunuz modelde, sınıflandırılacak tek özellik cihazın amacıdır - telefon, ağ anahtarı, bilgisayar, yönlendirici, vb. Her cihaz bu türlerden biri ve sadece biri olmalıdır. Örneğin, konum bir alt tür olmaz. IP adresi gibi özellikler süper türe aittir.

Sanırım cihaz türlerinin sayısının, başka bir cevapta belirtildiği gibi bir EAV modelini garanti edecek kadar büyük olacağını göreceksiniz. Referans verdiğim David Hay kitabı bu modeli çok etkili bir şekilde ele alıyor. Ancak, alt türlerin sayısı azsa, yalnızca birçok boş değerli sütun içeren bir süper tür tablo, yalnızca yinelenen sütunlara sahip alt tür tablolar veya her ikisini birden uygulamaya karar verdiğinizde genel bir kural kullanabilirsiniz. Her alt türün özniteliklerinde büyük farklılıklar varsa ve süper tür düzeyinde hiçbir ilişkisi yoksa, yalnızca alt tür tablolarla gidebilirsiniz. Bunun tersi doğruysa, yalnızca süper tür tablolarla gidebilirsiniz. Bir karışım varsa, her ikisini de uygulayın.

Son olarak, her zaman bir EAV desenini temel tablo şeması olarak uygulayabilir ve ardından verileri uygulamaya süper ve alt tür tablolar olarak sunan bir görünüm soyutlama katmanı oluşturabilirsiniz. Bu, depolama katmanında esneklik sağlar ancak uygulama görüntüleme katmanında anlama yeteneği sağlar.

Bir ürün envanter değildir. Envanter ve ürünler farklıdır.

Bir ürün, fiziksel bir şey değil, bir ürünün spesifikasyonudur.

Fiziksel olan şey, şirketin sahip olduğu (veya depoladığı) bir Varlıktır. Seri numarasına (ayrık varlıklar) göre izlediğiniz varlıklara veya yalnızca miktarlara göre izlediğiniz varlıklara (envanter varlıkları) sahip olabilirsiniz.

Silverston'un Veri Modeli Kaynak Kitabı Cilt 1'e bakardım. O proudcts, özellikler, fiyatlandırma, envanter için iyi bir şemaya sahiptir. Size çok zaman kazandıracak.

Sormak istediğim sorulardan biri, envanter öğelerinizin çeşitli özelliklerini neden izliyorsunuz? - Veya daha spesifik olarak, bu özellik bilgisiyle ne yapıyorsunuz?

Belirli öznitelikleri özel olarak anlamlandıran çok sayıda raporunuz veya formunuz varsa, ConcernedOfTunbridgeWell tarafından önerilen yaklaşımı kullanmanız gerekir. Öte yandan, bu özellikler onları listelemek veya muhtemelen benzer cihazların benzer özellikleriyle karşılaştırmak için kaydediliyorsa, aslında EAV kullanmak için (nadir) iyi bir bahaneniz olabilir. "EAV'nin saf kötülük olduğunu" biliyorum, bu nedenlerin belirli bir uygulama için önemli olmadığı çok nadir durumlar hariç. Sizinki böyle bir uygulama olabilir .

Bir cihaz envanter sisteminin tasarımı ile ilgili bu cevaba ve bir EAV yaklaşımının başvurunuzu nasıl basitleştirebileceğini görmek için bir ürün kataloğu sisteminin tasarımı ile ilgili bu cevaba bir göz atın . bu risklerin uygulamanız için geçerli olup olmayacağına karar verin.