Çoktan çoğa ilişkileri olan bir video oyunu iş alanı için bir veritabanı tasarlama


16

Veritabanı tasarımında nispeten yeniyim ve pratik için kendi varsayımsal veritabanımı yapmaya karar verdim. Bununla birlikte, sayısız çoktan çoğa (M: N) ilişki olduğuna saygı duyduğum için modelleme ve normalleştirme konusunda sorun yaşıyorum.

Genel senaryo açıklaması

Veritabanı, Zelda serisinde çalışan çeşitli Kişiler hakkındaki verileri tutmak içindir . Ben takip etmek istiyorum Konsol (s) bir o oyun çalınabilir, çalışanlar bir rol oldu Oyun geliştirme, İşler Çalışan (birçok vardı Çalışanlar farklı çalıştı İşler birden karşısında Games , vs.)

İş kuralları

  • Birden Fazla Çalışan birden fazla Oyun üzerinde çalışabilir .
  • Birden fazla oyun aynı konsolda olabilir .
  • Birden Çok Konsol aynı Oyun için bir platform olabilir .
  • Birden Çalışanlar aynı olabilir İşi .
  • Bir Çalışanın birden fazla İşi olabilir .
  • Bir Oyun birden fazla Çalışana sahip olabilir .
  • Bir Oyun birden fazla türde olabilir İşler 's gelişiminde
  • Birden Çok Oyun aynı türde İşe sahip olabilir .
  • Bir Konsol üzerinde çalışan birden fazla Kişi olabilir .
  • Bir Kişi birden fazla Konsolda çalışabilir .

Özellik adları ve örnek değerler

  • İlk ve Son olarak ayrılabilen Çalışan Adı (örneğin “John” ve “Doe”)
  • Oyun Başlığı (örneğin “Zamanın Ocarina”)
  • İş Unvanı (örneğin “Seviye Tasarımı”, “Yönetmen”, “Soğukkanlılık”, “Seviye Tasarımcısı”, “Programcı”, “Yerelleştirme” vb.).
  • Konsol Adı (örneğin “Game Boy Advance”)

Sorun

Şimdiye kadar, ne tasarladığım önemli değil, her yerde ilgilenen varlık türleri arasında veri fazlalıkları ve M: N ilişkileri var. Ancak veritabanı tasarımcılarının her zaman bu tür bir sorunla karşılaşmaları gerektiğini düşünüyorum, bu yüzden bir çözüm olmalı.


Not : Tabloyu doldurmak için verileri bulabiliyorum, sorun tabloları normalize edilmiş bir formda bir veritabanına organize etmektir.


Yanıtlar:


18

Evet, çoktan çoğa (kısalık için M: N) derneklerin veya ilişkilerin tanımlanması, bir veritabanı uygulayıcısının kavramsal bir şema hazırlarken oldukça yaygın olarak karşılaştığı bir durumdur. Söz konusu kardinalite oranlarını Dernekleri çok farklı nitelikteki iş ortamlarında hakkında gelir ve düzgün temsil zaman , örneğin bir SQL DDL düzenlemesi vasıtasıyla mantıksal düzeyde, onlar do not zararlı fazlalıklar tanıtmak.

Bu şekilde, bir veritabanı modelleme çalışmasının amacı, ilgili iş bağlamının ilgili özelliklerini yüksek hassasiyetle yansıtmak olmalıdır ; o zaman, N dernekler: doğru tanımlamak bu nedenle sayısız M olduğunu gerektiğini nasıl -OR sayıda bağlantı herhangi sıralı mantıksal seviye açıklamaları onları (a) kavramsal şemada ve ayrıca (b) 'de olursa olsun ifade diğer türden kardinalite oranlarının ele alınması gerekmektedir.

İş kuralları

Bağlamsallaştırılmış bir soru sağladınız ve üzerinde çalıştığınız veritabanının tamamen varsayımsal olduğunu açıkladınız. Bu önemli bir nokta, çünkü söz konusu olan gibi “gerçek dünya” iş senaryosunun çok daha geniş olacağına inanıyorum. dolayısıyla daha karmaşık bilgi gereklilikleri anlamına gelecektir.

(1) Daha açıklayıcı bir kavramsal şema üretmek için vermiş olduğunuz iş kurallarında birkaç değişiklik yapmaya ve genişletmeye karar verdim (yine de oldukça varsayımsal olsa da). İşte bir araya getirdiğim formülasyonlardan bazıları:

  • Bir Parti 1 ya bir olduğunu Kişi veya Kuruluş
  • Bir Parti tam-tek tarafından sınıflandırılır PartyType
  • Bir PartyType sınıflandırır sıfır-on-veya-çok taraf
  • Bir Kurum sıfır-bir-veya-çok Ürün geliştirir
  • Bir Ürün Bir Sistem veya Bir Oyun
  • Bir Ürün tam olarak kimse tarafından sınıflandırılır ProductType
  • Bir Sistem tam olarak bir SystemType tarafından kataloglanır
  • Bir Oyun bire çok Sistemlerle oynanabilir
  • Bir -çok Oyun oynamak için bir Sistem kullanılır
  • Bir Oyun , sıfır bir veya birçok Tarza göre sınıflandırılır
  • Bir Tarz Sıfır Bir veya Çok Sayıda Oyunu Sınıflandırır
  • Bir Ürün , bire çok İşten Kaynaklanır
  • Bir Job sıfır-bir-veya-birçok kişi tarafından yerine getirilir İnsanlar oynuyor, Rol arasında Ortak
  • Bir Kişi Bir olan İşbirlikçi sıfır-bir-veya-birçok İşler

1 Taraf , tek bir kişiyi oluşturan bir bireye veya bir grup kişiye atıfta bulunurken yasal bağlamlarda kullanılan bir terimdir, bu nedenle bu mezhep İnsanları ve Kuruluşları temsil etmek için uygundur .


IDEF1X diyagramı

Daha sonra, yukarıda sunulan iş kurallarını (alakalı görünen diğerleriyle birlikte) tek bir grafik cihazda birleştirerek , Şekil 1'de gösterilen IDEF1X 2 diyagramını oluşturdum (daha yüksek bir çözünürlükte görmek için bağlantıyı tıkladığınızdan emin olun):

Şekil 1 - Video Gae İşleri IDEF1X diyagramı


2 Bilgi Modelleme için Entegrasyon Tanımı ( IDEF1X ), Aralık 1993'te Amerika Birleşik Devletleri Ulusal Standartlar ve Teknoloji Enstitüsü (NIST) tarafından standart olarak oluşturulmuş, oldukça tavsiye edilen bir veri modelleme tekniğidir . (A) ilişkisel modelin tek yaratıcısı olan Dr. EF Codd tarafından yazılan erken teorik materyale dayanır; (b) Dr. PP Chen tarafından geliştirilen verilerin varlık-ilişki görüşü ; ve ayrıca (c) Robert G. Brown tarafından oluşturulan Mantıksal Veritabanı Tasarım Tekniğinde.


Gördüğünüz gibi, karşılık gelen ilişkilendirici varlık türleri yoluyla sadece üç M: N ilişkilendirmesini tasvir ettim , yani:

  • işbirlikçi
  • SystemGame
  • GameGenre

Diğer yönleri arasında, iki ayrı süper tip-alt tip yapı vardır, burada:

  • Kişi ve Organizasyon ait dışlayan varlık alt tipleri vardır Parti , kendi varlık süpertip

  • Ürün , Sistem ve Oyunun süpertipidir ve karşılığında birbirini dışlayan alt tiplerdir

Supertype-subtype derneklerine aşina değilseniz, yardım bulabilirsiniz, örneğin şu başlıklı sorulara cevaplarım:

Açıklayıcı mantıksal SQL-DDL düzeni

Art arda, mantıksal düzeyde emin olmalıyız:

  • Her varlık türü ayrı bir temel tablo ile temsil edilir
  • Uygulanabilir varlık türünün her bir özelliği belirli bir sütunla gösterilir
  • İçerdiği tüm değerlerin INT, DATETIME, CHAR, vb.Gibi belirli ve iyi tanımlanmış bir kümeye ait olmasını sağlamak için her sütun için kesin bir veri türü sabitlenir (elbette, örneğin Firebird veya PostgreSQL kullanılırken) , daha güçlü DOMAIN alanlarını kullanmak isteyebilirsiniz)
  • Tüm tablolarda tutulan satırlar biçimindeki iddiaların kavramsal düzeyde belirlenen iş kurallarına uymasını sağlamak için birden fazla kısıtlama (bildirimsel olarak) yapılandırılmıştır.

Bu yüzden daha önce gösterilen IDEF1X diyagramına dayalı olarak aşağıdaki DDL düzenlemesini beyan ettim:

CREATE TABLE PartyType ( -- Stands for an independent entity type.
    PartyTypeCode CHAR(1)  NOT NULL, -- To retain 'P' or 'O'.
    Name          CHAR(30) NOT NULL, -- To keep 'Person' or 'Organization'.
    --  
    CONSTRAINT PartyType_PK PRIMARY KEY (PartyTypeCode)
);

CREATE TABLE Party ( -- Represents an entity supertype.
    PartyId         INT       NOT NULL,
    PartyTypeCode   CHAR(1)   NOT NULL, -- To hold the value that indicates the type of the row denoting the complementary subtype occurrence: either 'P' for 'Person' or 'O' for 'Organization'.
    CreatedDateTime TIMESTAMP NOT NULL,  
    --
    CONSTRAINT Party_PK            PRIMARY KEY (PartyId),
    CONSTRAINT PartyToPartyType_FK FOREIGN KEY (PartyTypeCode)
        REFERENCES PartyType (PartyTypeCode)
);

CREATE TABLE Person ( -- Denotes an entity subtype.
    PersonId        INT      NOT NULL, -- To be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
    FirstName       CHAR(30) NOT NULL,
    LastName        CHAR(30) NOT NULL,
    GenderCode      CHAR(3)  NOT NULL,
    BirthDate       DATE     NOT NULL,
    --
    CONSTRAINT Person_PK PRIMARY KEY        (PersonId),
    CONSTRAINT Person_AK UNIQUE             (FirstName, LastName, GenderCode, BirthDate), -- Composite ALTERNATE KEY.
    CONSTRAINT PersonToParty_FK FOREIGN KEY (PersonId)
        REFERENCES Party (PartyId)
);

CREATE TABLE Organization ( -- Stands for an entity subtype.
    OrganizationId  INT      NOT NULL, -- To be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
    Name            CHAR(30) NOT NULL,
    FoundingDate    DATE     NOT NULL,
    --
    CONSTRAINT Organization_PK        PRIMARY KEY (OrganizationId),
    CONSTRAINT Organization_AK        UNIQUE      (Name), -- Single-column ALTERNATE KEY.
    CONSTRAINT OrganizationToParty_FK FOREIGN KEY (OrganizationId)
        REFERENCES Party (PartyId)
);

CREATE TABLE ProductType ( -- Represents an independent entity type.
    ProductTypeCode CHAR(1)  NOT NULL, -- To enclose the values 'S' and 'G' in the corresponding rows.
    Name            CHAR(30) NOT NULL, -- To comprise the values 'System' and 'Person' in the respective rows.
    --
    CONSTRAINT ProductType_PK PRIMARY KEY (ProductTypeCode)
);

CREATE TABLE Product ( -- Denotes an entity supertype.
    OrganizationId  INT      NOT NULL,
    ProductNumber   INT      NOT NULL,
    ProductTypeCode CHAR(1)  NOT NULL, -- To keep the value that indicates the type of the row denoting the complementary subtype occurrence: either 'S' for 'System' or 'G' for 'Game'.
    CreatedDateTime DATETIME NOT NULL,
    --
    CONSTRAINT Product_PK               PRIMARY KEY (OrganizationId, ProductNumber), -- Composite PRIMARY KEY.
    CONSTRAINT ProductToOrganization_FK FOREIGN KEY (OrganizationId)
        REFERENCES Organization (OrganizationId),
    CONSTRAINT ProductToProductType_FK  FOREIGN KEY (ProductTypeCode)
        REFERENCES ProductType (ProductTypeCode)
);

CREATE TABLE SystemType ( -- Stands for an independent entity type.
    SystemTypeCode CHAR(1)  NOT NULL,
    Name           CHAR(30) NOT NULL,
     --
    CONSTRAINT SystemType_PK PRIMARY KEY (SystemTypeCode)
);

CREATE TABLE MySystem ( -- Represents a dependent entity type.
    OrganizationId   INT      NOT NULL, -- To be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
    SystemNumber     INT      NOT NULL,
    SystemTypeCode   CHAR(1)  NOT NULL,
    ParticularColumn CHAR(30) NOT NULL,
    --
    CONSTRAINT System_PK              PRIMARY KEY (OrganizationId, SystemNumber),
    CONSTRAINT SystemToProduct_FK     FOREIGN KEY (OrganizationId, SystemNumber)
        REFERENCES Product (OrganizationId, ProductNumber),
    CONSTRAINT SystemToSystemType_FK  FOREIGN KEY (SystemTypeCode)
        REFERENCES SystemType (SystemTypeCode)
);

CREATE TABLE Game ( -- Denotes an entity subtype.
    OrganizationId INT      NOT NULL, -- To be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
    GameNumber     INT      NOT NULL,
    SpecificColumn CHAR(30) NOT NULL,
    --
    CONSTRAINT Game_PK          PRIMARY KEY (OrganizationId, GameNumber),
    CONSTRAINT GameToProduct_FK FOREIGN KEY (OrganizationId, GameNumber)
         REFERENCES Product (OrganizationId, ProductNumber)
);

CREATE TABLE Genre ( -- Stands for an independent entity type.
    GenreNumber INT      NOT NULL,
    Name        CHAR(30) NOT NULL,  
    Description CHAR(90) NOT NULL,
    --
    CONSTRAINT Genre_PK  PRIMARY KEY (GenreNumber),
    CONSTRAINT Genre_AK1 UNIQUE      (Name),
    CONSTRAINT Genre_AK2 UNIQUE      (Description)
);

CREATE TABLE SystemGame ( -- Represents an associative entity type or M:N association.
    SystemOrganizationId INT      NOT NULL,  
    SystemNumber         INT      NOT NULL,  
    GameOrganizationId   INT      NOT NULL,    
    GameNumber           INT      NOT NULL,
    CreatedDateTime      DATETIME NOT NULL,
    -- 
    CONSTRAINT SystemGame_PK         PRIMARY KEY (SystemOrganizationId, SystemNumber, GameOrganizationId, GameNumber), -- Composite PRIMARY KEY.
    CONSTRAINT SystemGameToSystem_FK FOREIGN KEY (SystemOrganizationId, SystemNumber) -- Multi-column FOREIGN KEY.
        REFERENCES MySystem (OrganizationId, SystemNumber),
    CONSTRAINT SystemGameToGame_FK   FOREIGN KEY (SystemOrganizationId, GameNumber) -- Multi-column FOREIGN KEY.
        REFERENCES Game (OrganizationId, GameNumber)  
);

CREATE TABLE GameGenre ( -- Denotes an associative entity type or M:N association.
    GameOrganizationId INT      NOT NULL,    
    GameNumber         INT      NOT NULL,
    GenreNumber        INT      NOT NULL,  
    CreatedDateTime    DATETIME NOT NULL,
    -- 
    CONSTRAINT GameGenre_PK        PRIMARY KEY (GameOrganizationId, GameNumber, GenreNumber), -- Composite PRIMARY KEY.
    CONSTRAINT GameGenreToGame_FK  FOREIGN KEY (GameOrganizationId, GameNumber)
        REFERENCES Game (OrganizationId, GameNumber), -- Multi-column FOREIGN KEY.
    CONSTRAINT GameGenreToGenre_FK FOREIGN KEY (GenreNumber)
        REFERENCES Genre (GenreNumber) 
);

CREATE TABLE Job ( -- Stands for an associative entity type or M:N association.
    OrganizationId  INT      NOT NULL,
    ProductNumber   INT      NOT NULL,
    JobNumber       INT      NOT NULL,
    Title           CHAR(30) NOT NULL,  
    CreatedDateTime DATETIME NOT NULL,
    --
    CONSTRAINT Job_PK          PRIMARY KEY (OrganizationId, ProductNumber, JobNumber), -- Composite PRIMARY KEY.
    CONSTRAINT Job_AK          UNIQUE      (Title), -- Single-column ALTERNATE KEY.
    CONSTRAINT JobToProduct_FK FOREIGN KEY (OrganizationId, ProductNumber) -- Multi-column FOREIGN KEY.
        REFERENCES Product (OrganizationId, ProductNumber)
);

CREATE TABLE Collaborator ( -- Represents an associative entity type or M:N association.
    CollaboratorId   INT      NOT NULL,    
    OrganizationId   INT      NOT NULL,
    ProductNumber    INT      NOT NULL,
    JobNumber        INT      NOT NULL,
    AssignedDateTime DATETIME NOT NULL,
    --
    CONSTRAINT Collaborator_PK         PRIMARY KEY (CollaboratorId, OrganizationId, ProductNumber, JobNumber), -- Composite PRIMARY KEY.
    CONSTRAINT CollaboratorToPerson_FK FOREIGN KEY (CollaboratorId)
    REFERENCES Person (PersonId),  
    CONSTRAINT CollaboratorToJob_FK    FOREIGN KEY (OrganizationId, ProductNumber, JobNumber) -- Multi-column FOREIGN KEY.
       REFERENCES Job (OrganizationId, ProductNumber, JobNumber)
);

Kavramsal varlık türleri arasında gerçekleşen bağlantıların hiyerarşisi, örneğin SELECT ifade edildiğinde veri alımı açısından çok faydalı olabilecek düzenleme hiyerarşisi anlamına gelen, birkaç tablo arasında bileşik PRIMARY KEY kısıtlamaları bildirimlerinin olduğunu vurgulamak mümkündür. türetilmiş tablolar elde etmek için JOIN yan tümcelerini içeren işlemler .

Evet, (i) her M: N derneği ve (ii) ilişkili varlık türlerinin her biri (iii) mantıksal DDL yapısındaki karşılık gelen tablo ile gösterilir, bu nedenle PRIMARY ve FOREIGN KEY kısıtlamalarına (ve notları yorum olarak bıraktım) bu kavramsal elemanları temsil eden tablolar, çünkü ilgili satırlar arasındaki bağlantıların geçerli kardinalite oranlarını karşılamasına yardımcı olurlar.

Kompozit anahtarların kullanımı, Dr. EF Codd tarafından, büyük Paylaşılan Veri Bankaları için İlişkisel Model başlıklı 1970 tarihli makalesinde (örn. kavramsal M: N derneklerini ele almak için en şık yöntem).

Her ikisi de Microsoft SQL Server 2014 üzerinde çalışan bir db <> keman ve bir SQL Fiddle , böylece yapı "eylem" test edilebilir koymak .

normalleştirme

Normalleştirme, temel olarak şunu ifade eden mantıksal bir prosedürdür:

  1. İlk normal form aracılığıyla atom olmayan sütunların ortadan kaldırılması, böylece veri manipülasyonu ve daralması, veri alt dili kullanımıyla (örn. SQL) başa çıkmak için çok daha kolaydır.

  2. Güncelleme anormalliklerinden kaçınmak için ardışık normal formlar sayesinde belirli bir tablonun sütunları arasındaki istenmeyen bağımlılıklardan kurtulmak .

Doğal olarak, söz konusu tablo (lar) ve sütun (lar) tarafından taşınan anlamı dikkate almak gerekir .

Normalleşmeyi , bir tasarımcının, öğelerinin normal formların her birine uyup uymadığını belirlemek için kararlı bir mantık düzeyi düzenlemeyi tanımladıktan sonra ilgili öğelere uyguladığı bilim üzerine kurulmuş bir test olarak düşünmeyi seviyorum . Ardından, gerekirse, tasarımcı uygun düzeltme önlemlerini alır.

fazlalık

İlişkisel modelde, sütunlarda bulunan değerlerin çoğaltılması sadece kabul edilebilir değil , aynı zamanda beklenen , yinelenen satırlar yasaktır . Bu ölçüde, görebildiğim kadarıyla, daha önce açıklanan mantıksal düzende yer alan tüm tablolarda yinelenen satırlar ve diğer zararlı fazlalıklar önlenir, belki de bu konudaki endişenizi açıklığa kavuşturmak istersiniz.

Her neyse, (a) gereklilikleri karşılayıp karşılamadığını tanımlamak ve (b) gerekirse değiştirmek için normal yapıların dint'i ile söz konusu yapınızı kendi başınıza değerlendirebilirsiniz.

Alakalı kaynaklar

  • Bu yazı dizisinde, iki farklı varlık türünün örneklerini birbiriyle ilişkilendirebilecek basit bir M: N ilişkilendirmesi hakkında bazı görüşmeler sunuyorum .
  • Olarak , bu diğer bir ettiği bir şekilde bağlanabilmesi için tarif “Malzeme Listesinde” veya “parçalar Patlama” yapısı, bir oluşumu işlemek için bir yaklaşım öneriyoruz farklı örneklerini aynı kişinin türüne.

Üçlü dernekler

Yorumlarla gündeme getirdiğiniz başka bir önemli nokta daha var (şimdi silinmiş bir cevapta yayınlanmıştır):

Ne zaman bir köprü yapmaya çalışsam, o köprüdeki öğelerin de Çoktan Çoka sahip olduğu, izin verilmeyen ya da en azından cesareti kırılmış izlenim altındayım.

Bu durum, endişelerinizden birinin kavramsal üçlü derneklerle ilgili olduğunu göstermektedir . Temel olarak, bu tür çağrışımlar ortaya çıktığında ortaya çıkar (1) diğer iki ilişkiyi içeren bir ilişki (2), diğer bir deyişle “ilişkiler arasındaki ilişki” - tipik bir durum, çünkü ilişki kendi başına bir varlıktır -.

Bu düzenlemeler uygun şekilde yönetildiğinde zararlı fazlalık getirmez. Ve evet, bu tür ilişkilerin kendilerini “gerçek dünya” varlık türleri arasında sunduğunu belirlediğiniz belirli bir kullanım durumu varsa, (i) modellemek ve (ii) bunları mantıksal düzeyde doğrulukla beyan etmek zorundasınız.

  • İşte bir soru ve cevap , üçlü bir ilişki örneği içeren anketlerle ilgili bir söylem alanını analiz ediyorduk .
  • Gelen bu çok iyi bir cevap , @Ypercube ilginç bir diyagram ve ilgili DDL yapı arz elmas biçimli ilişkinin senaryoların bu sınıfa çok benzer.
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.