Membuat model skenario di mana masing-masing Artis Musik adalah Kelompok atau Pelaku Solo


12

Saya harus mendesain diagram entitas-hubungan (ERD) untuk konteks bisnis yang melibatkan penggambaran seniman musik , seperti yang akan saya uraikan di bawah ini.

Deskripsi skenario

  • Sebuah Artis memiliki Nama , dan harus baik sebuah kelompok atau sebuah Performer Solo (tapi tidak keduanya).

  • Sebuah kelompok terdiri dari satu atau lebih Pelaku Solo dan memiliki Jumlah Anggota (yang harus dihitung dari jumlah Pelaku Solo yang membentuk Grup ).

  • Seorang Pelaku Solo dapat menjadi Anggota dari banyak Grup atau tanpa Grup dan dapat memainkan satu atau lebih Instrumen .

Pertanyaan

Bagaimana cara membangun ERD untuk mewakili skenario seperti itu? Saya bingung dengan bagian 'atau' itu.

Jawaban:


15

Bagian dari skenario yang Anda bingung dapat dimodelkan dengan konstruksi klasik yang disebut struktur supertype-subtype 1 .

Saya akan (1) memperkenalkan beberapa ide awal yang relevan, (2) menjelaskan bagaimana saya akan menggambarkan — pada tingkat konseptual — konteks bisnis yang sedang dipertimbangkan, dan (3) memberikan materi terkait terkait — misalnya, representasi tingkat logis yang sesuai melalui SQL Deklarasi -DDL— sebagai berikut.

pengantar

Struktur sifat ini terjadi ketika, dalam lingkungan bisnis tertentu, ada sekelompok jenis entitas di mana supertype memiliki satu atau lebih properti (atau atribut) yang dibagi oleh sisa jenis entitas dalam cluster, yaitu , subtipe . Setiap subtipe memiliki, pada gilirannya, seperangkat properti tertentu yang hanya berlaku untuk dirinya sendiri.

Cluster Supertype-subtype dapat terdiri dari dua jenis:

  • Eksklusif . Terjadi ketika sebuah instance dari tipe superentity harus selalu memiliki satu dan hanya satu subtipe; oleh karena itu, kejadian subtipe potensial yang dipertanyakan adalah saling eksklusif . Ini adalah jenis yang berkaitan dengan skenario Anda.

    Kasus khas di mana subtipe supertype eksklusif muncul adalah domain bisnis di mana baik Organisasi dan Seseorang dianggap sebagai Pihak Hukum , seperti dalam situasi yang dibahas dalam serangkaian posting ini .

  • Tidak ada yang eksklusif . Hadir dengan sendirinya ketika instance supertype dapat dilengkapi dengan beberapa kejadian subtipe , yang masing-masing dipaksa dari kategori yang berbeda .

    Contoh jenis subtipe supertipe ini dibahas dalam posting ini .

Catatan : Perlu disebutkan bahwa struktur subtipe supertipe — menjadi elemen karakter konseptual — tidak termasuk dalam kerangka kerja teoritis manajemen data tertentu, baik itu relasional, jaringan, atau hierarkis — masing-masing menawarkan struktur tertentu untuk mewakili elemen konseptual—.

Ini juga tepat untuk menunjukkan bahwa meskipun kluster supertipe-subtipe memiliki kemiripan tertentu dengan pewarisan dan aplikasi polimorfisme pemrograman berorientasi objek (OOP) , mereka sebenarnya adalah perangkat yang berbeda karena mereka melayani tujuan yang berbeda. Dalam model konseptual database - yang harus mewakili aspek dunia nyata - seseorang berurusan dengan fitur struktural untuk menggambarkan persyaratan informasi , sedangkan dalam OOP polimorfisme dan pewarisan, antara lain, satu (a) sketsa dan (b) menerapkan karakteristik komputasi dan perilaku , aspek yang jelas milik desain dan pemrograman program aplikasi.

Selain itu, sebuah OOP individu kelas -Menjadi program component- aplikasi, tidak tidak perlu harus “cermin” struktur jenis entitas individu yang dimiliki tingkat konseptual database di tangan. Dalam hal ini, seorang pemrogram aplikasi biasanya dapat membuat, misalnya, satu kelas tunggal yang "menggabungkan" semua properti dari dua (atau lebih) tipe entitas tingkat konseptual yang berbeda, dan kelas semacam itu juga dapat mencakup properti yang dikomputasi.

Menggunakan konstruksi hubungan entitas untuk mewakili model konseptual dengan struktur subtipe-supertipe

Anda meminta diagram hubungan entitas (ERD for brevity) tetapi, meskipun menjadi platform pemodelan yang luar biasa, metode asli - seperti yang diperkenalkan oleh Dr. Peter Pin-Shan Chen 2 - tidak menyediakan konstruksi yang cukup untuk mewakili skenario dari jenis yang sedang dibuat. dibahas dengan presisi yang dibutuhkan oleh model konseptual database.

Akibatnya, perlu untuk membuat beberapa ekstensi untuk metode tersebut, situasi yang menghasilkan hasil dalam pengembangan pendekatan yang membantu dalam pembuatan diagram hubungan entitas yang ditingkatkan (EERDs) yang, secara alami, memperkaya teknik diagram awal dengan karakteristik ekspresif baru . Salah satu karakteristik itu, tepatnya, kemungkinan menggambarkan struktur subtipe-supertipe.

Membuat model konteks minat Anda

Ilustrasi yang ditunjukkan pada Gambar 1 adalah EERD (menggunakan simbol yang mirip dengan yang diusulkan oleh Ramez A. Elmasri dan Shamkant B. Navathe 3 , yang merujuk pada struktur seperti superclass / subclass ) di mana saya memodelkan domain bisnis yang Anda gambarkan dengan mempertimbangkan semua spesifikasi. Ini juga tersedia dalam bentuk PDF yang dapat diunduh dari Dropbox .

Seperti yang Anda lihat pada diagram di atas, keduanya Groupdan SoloPerformerditampilkan sebagai subtipe eksklusif dari Artisttipe superentitas:

Artis Musik Enhanced Entity-Relationship Diagram

Deskripsi diagram

Untuk memulai deskripsi EERD, penting untuk menunjukkan bahwa kalimat Anda

  • “Artis harus berupa Grup atau SoloPerformer (tetapi tidak keduanya)”

terkait dengan disjointness dan aspek kelengkapan dari supertype-subtype cluster yang ada.

Ketidakcocokan

Fitur disjointness sangat penting karena di sinilah "atau bagian" yang Anda sebutkan berperan, karena fakta bahwa Artistharus salah satu contoh subtipe atau yang lain, yang saya tentukan dalam EERD melalui kecil lingkaran yang berisi huruf "d", sebuah konstruk yang menerima nama aturan disjoint .

Ketika supertipe dapat dilengkapi dengan satu atau lebih subtipe yang mungkin, titik ini harus dinyatakan oleh lingkaran kecil yang memegang label dengan huruf "o", simbol yang disebut aturan tumpang tindih .

Properti diskriminator

Juga dalam lingkup faktor disjointness dari asosiasi supertipe-subtipe ini, ada baiknya memperhatikan Artist.Typeproperti, karena melakukan tugas yang sangat relevan dalam pengaturan ini: berfungsi sebagai pembeda subtipe . Ini dinamai dengan cara ini karena itu adalah properti yang menunjukkan jenis subtipe eksklusif yang terkait dengan contoh spesifik Artist.

Dalam kasus cluster noneksklusif , penggunaan properti diskriminator tidak perlu, karena supertype tertentu dapat memiliki beberapa subtipe sebagai pelengkap (seperti yang dijelaskan di atas).

Aturan dan kelengkapan spesialisasi total

Persyaratan yang menetapkan bahwa setiap orang Artistharus selalu memiliki turunan subtipe pelengkap berkaitan dengan karakteristik kelengkapan gugus ini. Ini digambarkan dengan menggunakan aturan spesialisasi total , ditunjukkan melalui simbol garis ganda yang menghubungkan (a) Artistsupertype dengan (b) konstruk aturan disjoint.

Menghubungkan Grup dengan Pemain Solo

Mengevaluasi kalimat

  • Grup terdiri dari satu atau lebih SoloPerformers

dan

  • Pelaku Solo dapat menjadi anggota dari banyak Grup atau tanpa Grup ”,

kita dapat mengenali bahwa kedua subtipe terlibat dalam asosiasi (atau hubungan) banyak-ke-banyak (M: N), yang saya wakili dengan kotak berbentuk berlian yang berlabel Group-SoloPerformer.

Jika diimplementasikan dalam relasional database sebagai sebuah basis tabel, komponen ini akan sangat berguna untuk Turunkan (yaitu, untuk melaksanakan perhitungan) total Numberdari SoloPerformersmake up yang beton Group(salah satu persyaratan yang Anda tentukan).

Hubungan antara Pelaku dan Instrumen Solo

Ketentuannya

  • “Seorang SoloPerformer [...] dapat memainkan satu atau lebih Instrumen”

memungkinkan kita menyimpulkan bahwa, pada saat yang sama,

  • "Instrumen dimainkan oleh nol, satu atau lebih SoloPerformers".

Jadi, ini adalah contoh lain dari asosiasi M: N, dan saya menggunakan sosok berbentuk berlian yang ditunjuk SoloPerformer-Instrumentuntuk mengeksposnya.

Material tambahan

Untuk menjelaskan ruang lingkup struktur subtipe-supertipe saya akan menyertakan dua sumber daya lagi, yaitu,

  1. diagram IDEF1X 4 yang disajikan dalam Gambar 2 ( dan Anda juga dapat mengunduhnya dari Dropbox sebagai PDF ) yang mengilustrasikan kemampuan ekspresif diagram semacam ini terkait dengan domain bisnis yang dipermasalahkan; dan

  2. struktur logis DDL ekspositoris masing-masing yang mencontohkan bagaimana mengelola skenario penuh dalam diskusi berdasarkan sistem manajemen database SQL.

1. Representasi IDEF1X

Teknik pemodelan informasi IDEF1X tentu saja menawarkan kemampuan untuk menggambarkan struktur subtipe-supertipe, walaupun dengan batasan: teknik peminjaman tidak menunjukkan mekanisme visual untuk menunjukkan apakah kluster yang tepat adalah jenis yang eksklusif atau tidak eksklusif (simbol "asli" -nya hanya dapat berkomunikasi yang lengkap atau tidak lengkap identifikasi semua kemungkinan jenis subentity signifikansi). Untungnya, orang dapat menggunakan notasi Information Engineering (IE) untuk menunjukkan aspek terpenting ini lebih akurat sambil mengambil keuntungan dari kekuatan deskriptif standar IDEF1X.

Dalam teknik ini, fitur utama dari pertanyaan Anda adalah "hubungan kategorisasi" dalam denominasi, di mana supertype disebut sebagai "entitas generik" dan subtipe menerima nama "entitas kategori". Namun, saya akan terus menerapkan istilah supertipe-subtipe dalam posting ini karena (1) digunakan oleh Dr. Edgar Frank Codd, pencetus model relasional, (2) lebih dikenal luas dan (3) notasi IE adalah digunakan bukan yang "asli".

Artis Musik Diagram IDEF1X

Kunci asing dan klaster supertipe-subtipe

Seperti yang ditunjukkan, IDEF1X memberikan keuntungan lebih lanjut: sarana untuk menunjukkan FOREIGN KEY (FK) definisi, elemen terpenting jika seorang praktisi akan mewakili asosiasi supertype-subtipe dalam relasional database yang.

Untuk menggambarkan asosiasi semacam itu, properti PRIMARY KEY (PK) dari supertype, yaitu Artist.ArtistNumber, harus bermigrasi ke Groupdan SoloPerformer, meskipun telah ditetapkan dua nama peran yang berbeda 5, 6 , GroupNumberdan SoloPerformerNumbermasing - masing, dengan tujuan untuk menekankan yang artinya disampaikan oleh properti dalam konteks masing-masing jenis subentity.

Selain dicirikan sebagai PK, properti Group.GroupNumberdan SoloPerformer.SoloPerformerNumber, pada saat yang sama, digambarkan sebagai KUNCI LUAR NEGERI (FK) yang membuat referensi ke Artist.ArtistNumber, properti PK supertipe.

Jadi, karena setiap SoloPerformerdan Groupkejadian tergantung pada keberadaan pada Artistcontoh yang tepat , tipe entitas ini terlibat dalam asosiasi pengidentifikasi yang berlaku melalui proses migrasi properti PK yang dijelaskan dalam paragraf sebelumnya.

Kunci asing dan jenis entitas asosiatif

Diagram IDEF1X berfungsi juga untuk menggambarkan FK yang menyusun PK dari dua jenis entitas asosiasi yang relevan, yaitu, GroupMemberdan SoloPerformerInstrument; yang pertama menghubungkan dua subtipe, dan yang kedua menghubungkan subtipe dengan tipe entitas independen, yaitu Instrument,.

2. Deklarasi logis Expository SQL-DDL

Seperti dijelaskan sebelumnya, struktur subtipe-supertipe adalah sarana untuk mengekspresikan jenis tertentu konseptualisasi bisnis-domain-spesifik mengenai persyaratan informasi, yang pada gilirannya dapat direpresentasikan dalam basis data dengan menggunakan konstruksi berbeda yang harus sesuai dengan yang ditawarkan oleh pihak tertentu paradigma teoretis (baik relasional, jaringan atau hierarkis) diikuti oleh sistem manajemen basis data yang digunakan oleh perancang.

Salah satu keuntungan berganda dari paradigma relasional adalah bahwa ia memungkinkan merepresentasikan informasi dalam struktur alaminya, dan perkiraan paling populer untuk sistem yang diusulkan dalam teori relasional adalah berbagai sistem manajemen basis data SQL.

Jadi, akhirnya, berikut adalah beberapa contoh pernyataan DDL — termasuk (a) skema tabel dasar bersama dengan (b) beberapa kendala terkait — yang mewakili, pada tingkat abstraksi logis, latihan pemodelan konseptual yang diperlakukan di atas:

--
--
CREATE TABLE Artist ( -- Stands for the supertype.
    ArtistNumber    INT      NOT NULL,
    Name            CHAR(30) NOT NULL,
    Type            CHAR(1)  NOT NULL, -- Holds the discriminator values.
    CreatedDateTime DATETIME NOT NULL,
    --
    CONSTRAINT Artist_PK      PRIMARY KEY (ArtistNumber),
    CONSTRAINT Artist_AK      UNIQUE      (Name), -- ALTERNATE KEY.
    CONSTRAINT Artist_Type_CK CHECK       (Type IN ('G', 'S')) -- Enforces retaining either ‘G’, for ‘Group’, or ‘S’, for ‘SoloPerformer’, only.
);

CREATE TABLE MyGroup ( -- Represents one subtype.
    GroupNumber   INT  NOT NULL, -- To be constrained as PK and FK simultaneously.
    FormationDate DATE NOT NULL,
    --
    CONSTRAINT MyGroup_PK         PRIMARY KEY (GroupNumber),
    CONSTRAINT MyGroupToArtist_FK FOREIGN KEY (GroupNumber)
        REFERENCES Artist (ArtistNumber)  
);

CREATE TABLE SoloPerformer ( -- Denotes the other subtype.
    SoloPerformerNumber INT  NOT NULL, -- To be constrained as PK and FK simultaneously.
    BirthDate           DATE NOT NULL,
    --
    CONSTRAINT SoloPerformer_PK               PRIMARY KEY (SoloPerformerNumber),
    CONSTRAINT SoloPerformerNumberToArtist_FK FOREIGN KEY (SoloPerformerNumber)
        REFERENCES Artist (ArtistNumber)  
);

CREATE TABLE GroupMember ( -- Stands for a M:N association involving the two subtypes.
    MemberNumber INT  NOT NULL,
    GroupNumber  INT  NOT NULL,
    JoinedDate   DATE NOT NULL,
    --
    CONSTRAINT GroupMember_PK                PRIMARY KEY (MemberNumber, GroupNumber), -- Composite PK.
    CONSTRAINT GroupMemberToSoloPerformer_FK FOREIGN KEY (MemberNumber)
        REFERENCES SoloPerformer (SoloPerformerNumber),
    CONSTRAINT GroupMemberToMyGroup_FK       FOREIGN KEY (GroupNumber)
        REFERENCES MyGroup       (GroupNumber)  
);

CREATE TABLE Instrument ( -- Represents an independent entity type.
    InstrumentNumber INT      NOT NULL,
    Name             CHAR(30) NOT NULL,
    --
    CONSTRAINT Instrument_PK PRIMARY KEY (InstrumentNumber),
    CONSTRAINT Instrument_AK UNIQUE      (Name) -- ALTERNATE KEY.  
);

CREATE TABLE SoloPerformerInstrument ( -- Denotes another M:N association, in this case between a subtype and an independent entity type.
    SoloPerformerNumber INT  NOT NULL,
    InstrumentNumber    INT  NOT NULL,
    CreatedDate         DATE NOT NULL,
    --
    CONSTRAINT SoloPerformerInstrument_PK                PRIMARY KEY (SoloPerformerNumber, InstrumentNumber), -- Composite PK.
    CONSTRAINT SoloPerformerInstrumentToSoloPerformer_FK FOREIGN KEY (SoloPerformerNumber)
        REFERENCES SoloPerformer (SoloPerformerNumber),
    CONSTRAINT SoloPerformerInstrumentToInstrument_FK    FOREIGN KEY (InstrumentNumber)
        REFERENCES Instrument    (InstrumentNumber)  
);
--
--

Integritas data dan pertimbangan konsistensi

Dalam perjanjian dengan semua yang telah dijelaskan sebelumnya, perancang harus menjamin bahwa setiap baris “supertype” setiap saat dilengkapi dengan rekanan “subtype” yang menyertainya dan, pada gilirannya, memastikan bahwa baris “subtype” tersebut sesuai dengan nilai. terkandung dalam kolom "diskriminator" supertipe.

Akan sangat praktis dan elegan untuk menegakkan keadaan tersebut secara deklaratif (sebagaimana kerangka kerja mengusulkan) tetapi, sayangnya, tidak ada platform SQL utama yang menyediakan mekanisme yang sesuai untuk melakukannya (sejauh yang saya tahu). Oleh karena itu, sangat nyaman untuk menggunakan TRANSAKSI ASAM sehingga kondisi ini selalu dipenuhi dalam basis data (opsi lain adalah menggunakan PEMICU, tetapi mereka cenderung membuat hal-hal tidak rapi).

Pertimbangan derivasi data

Salah satu aspek utama dari model relasional adalah mempertimbangkan derivasi data sebagai faktor terpenting dalam manajemen data. Sesuai, ia memfasilitasi menciptakan (a) dasar hubungan -atau dasar tabel di SQL, seperti yang ditunjukkan dalam DDL pernyataan di atas dan di (b) berasal hubungan - berasal tabel di SQL, yaitu, mereka menyatakan dengan berkat operasi SELECT yang mungkin ditetapkan sebagai pandangan untuk eksploitasi lebih lanjut—.

Jadi, seseorang dapat mendeklarasikan tampilan yang mengumpulkan poin data Grup "penuh" :

CREATE VIEW FullGroup AS
    SELECT G.GroupNumber,
           A.Name,
           A.CreatedDateTime,
           G.FormationDate
         FROM Artist A
         JOIN MyGroup G 
           ON G.GroupNumber = A.ArtistNumber;

Dan tampilan lain yang menggabungkan informasi SoloPerformer "penuh" :

CREATE VIEW FullSoloPerformer AS
    SELECT SP.SoloPerformerNumber,
            A.Name,
            A.CreatedDateTime,
           SP.BirthDate
         FROM Artist A
         JOIN SoloPerformer SP 
           ON SP.SoloPerformerNumber = A.ArtistNumber;

Dengan cara ini, sangat mudah untuk memanipulasi —declaratif — semua data signifikan melalui perangkat level logis yang sama, yaitu relasi atau tabel (baik basis atau turunannya). Jelas, penggunaan pandangan lebih efektif ketika jenis entitas konseptual yang diwakili dalam database relasional memiliki lebih banyak sifat yang menarik, tetapi kemungkinan layak diilustrasikan dengan skenario saat ini.


Referensi

1 Codd, EF (Desember 1979). Memperluas Model Relasional Basis Data untuk Mengabadikan Lebih Berarti , Transaksi ACM pada Sistem Basis Data , Volume 4 Edisi 4 (hal. 397-434). New York, NY, AS.

2 Chen, PP (Maret 1976). Model Entity-Relationship — Menuju Pandangan Terpadu Data , Transaksi ACM tentang Sistem Basis Data - Masalah khusus: Makalah dari Konferensi Internasional tentang Pangkalan Data Sangat Besar: 22-24 September 1975, Framingham, MA , Volume 1 Edisi 1 (hal. . 9-36). New York, NY, AS.

3 Elmasri, R & Navathe, SB (2003). Dasar-dasar Sistem Basis Data , Edisi Keempat. Addison-Wesley Longman Publishing Co, Inc. Boston, MA, AS.

4 Institut Standar dan Teknologi Nasional (AS) [NIST] (Desember 1993). Definisi Integrasi untuk Pemodelan Informasi (IDEF1X), Publikasi Standar Pemrosesan Informasi Federal , Volume 184. AS.

5 Codd, EF (Juni 1970). Model Relasional Data untuk Bank Data Besar Bersama , Komunikasi ACM , Volume 13 Edisi 6 (hal. 377-387). New York, NY, AS.

6 Lihat referensi 4


4

Jawaban oleh MDCCL menarik, mendidik, dan mungkin benar (meskipun di atas nilai gaji saya).

Sebaliknya, saya menafsirkan kembali Pertanyaan dan kembali ke dasar-dasar untuk solusi sesederhana mungkin. Mungkin saya curang dan tidak benar-benar menjawab Pertanyaan ... tapi begini saja.

Saya bingung ketika membaca dan membaca kembali Pertanyaan. Ketika melihat istilah "Artis", saya terus memikirkan orang secara individu. Tapi tidak, itu dimaksudkan dalam arti "label merek artistik", seperti album rekaman musik memiliki judul dan "artis" apakah artis tersebut menjadi individu seperti Johnny Cash atau grup seperti The Cure .

Mari kita ambil contoh artis yang sekarang dikenal sebagai Pangeran . Dia menerbitkan album sebagai:

  • Pangeran
  • Prince & The Revolution
  • Pangeran & Pembangkit Listrik Baru
  • [ simbol ubahsuaian ]

Keempatnya akan menjadi contoh "Artis". Secara khusus, ada dua wanita, Wendy Melvoin dan Lisa Coleman, di bandnya The Revolution tetapi tidak di New Power Generation , setelah berangkat untuk melanjutkan karir mereka di bawah merek Wendy & Lisa .

Jadi, kita akan memiliki contoh lain dari "Artis" dengan Wendy & Lisa sementara individu Melvoin dan Coleman masing-masing akan menjadi pemain tetapi bukan "Artis". Para wanita tersebut akan ditugaskan sebagai Pelaku untuk dua "Artis" ((1) Prince & The Revolution , (2) Wendy & Lisa ).

Diagram berikut adalah upaya kikuk untuk menunjukkan contoh data ini secara kompak. Kami menunjukkan dua wanita yang digarisbawahi (Performer) milik dua band yang berbeda (Artis). Dan kami menunjukkan pria yang dicetak miring, Pangeran, milik empat band (Artis) tetapi bukan milik band terakhir (Artis).

masukkan deskripsi gambar di sini

Jika itu menggambarkan domain bisnis, maka saya akan mengusulkan desain tabel berikut (dan ERD).

Diagram desain tabel Artis, Keanggotaan, Pemain, Pemain, Instrumen

Pada dasarnya kami memiliki sepasang hubungan Many-To-Many:

  • Seorang Artis (baik solo atau band) adalah satu atau lebih Penampil yang ditugaskan. Dan Performer dapat menjadi anggota dari satu atau lebih "Artis" / band.
  • Seorang Performer dapat memainkan satu atau lebih instrumen. Dan setiap Instrumen dapat memiliki banyak Pemain yang terdaftar yang mampu memainkannya.

Adapun "Grup" dan "SoloPerformer":

  • "Solo" hanyalah "Artis" dengan hanya satu "Pelaku" yang ditugaskan.
    (Hanya satu catatan anak di tabel Keanggotaan yang memiliki ID Artis yang ditetapkan sebagai kunci asing.)
  • "Grup" adalah "Artis" mana saja dengan lebih dari satu "Pelaku" ditugaskan.
    (Dua atau lebih catatan anak di tabel Keanggotaan memiliki ID Artis yang ditetapkan sebagai kunci asing.)

Jika bagian dari logika bisnis adalah untuk membedakan antara item Artis yang Solo vs Grup, kita dapat dalam SQL melakukan kueri untuk baris Artis yang hanya memiliki satu baris tabel Keanggotaan dibandingkan yang memiliki banyak. Namun secara praktis, mungkin masuk akal untuk mendenormalisasi informasi ini dengan:

  • Menambahkan Boolean "Solo / Grup" di tabel Artis, dan…
  • Menegakkan keanggotaan tunggal / banyak ini dalam aplikasi.

Jika tujuan Pertanyaan adalah untuk menegakkan perbedaan Solo versus Grup dalam struktur basis data (atau ERD), maka saya telah gagal. Namun demikian, saya harap jawaban ini terbukti menarik dan bermanfaat.


Perspektif yang sangat baik
Pmpr

2

Jawaban dari MDCCL adalah ringkasan luar biasa dari konsep-konsep di balik superclass / subclass atau generalisasi / spesialisasi seperti yang digambarkan pada tingkat EERD.

Jawaban ini dimaksudkan untuk menunjukkan tiga pola desain atau teknik yang perlu diketahui ketika saatnya tiba untuk mengubah EERD menjadi desain relasional, berdasarkan tabel yang ditentukan dengan kolom yang ditentukan.

Inilah ketiganya:

  • Warisan Kelas Tunggal
  • Warisan Tabel Kelas
  • Kunci Utama Bersama

Dua yang pertama adalah alternatif, satu baik untuk kasus-kasus sederhana di mana hampir semua data berkaitan dengan superclass. Yang kedua lebih rumit, tetapi dapat bekerja lebih baik ketika banyak data berkaitan dengan beberapa subkelas. Kata "Warisan" digunakan untuk menunjukkan bahwa desain menyediakan beberapa kekuatan ekspresif yang sama yang akan diberikan warisan dalam model objek.

Kunci utama bersama adalah teknik di mana entri dalam tabel subkelas dapat memperoleh identitas dengan "mewarisi" identitas entri yang sesuai dalam tabel superclass.

Di SO, ada tiga tag dengan nama-nama ini. Tab Info di bawah setiap tag memberikan deskripsi, dan ada banyak pertanyaan yang dikelompokkan di bawah tag.

Ada juga banyak situs web yang menyajikan teknik ini. Saya merekomendasikan yang dari Martin Fowler. Saya suka cara dia menyajikannya. Berikut adalah beberapa halaman web:

Tabel Tunggal Warisan Kelas

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.