MANAJEMEN PROYEK PERANGKAT LUNAK

Assalammualaikum Wr. Wb.

Setelah sekian lama tidak membuat note, akhirnya saya membuat lagi untuk pertama kalinya di tahun 2019. Di tahun 2019 ini saya akan memberikan catatan tentang manajemen proyek perangkat lunak.

MANAJEMEN PROYEK PERANGKAT LUNAK

Sebelum mengetahui apa itu manajemen proyek perangkat lunak, kita harus tahu apa itu manajemen, proyek dan perangkat lunak tersebut. Berikut ini penjelasannya :

A.  Manajemen

Ada beberapa pengertian manajemen menurut para ahli. Berikut ini pengertian manajemen menurut para ahli :

1.   George R. Terry

Manajemen adalah proses yang khas yang terdiri dari tindakan-tindakan: perencanaan, pengorganisasian, penggerakan, dan pengawasan yang dilakukan untuk menentukan serta mencapai sasaran-sasaran yang telah ditetapkan melalui pemanfaatan sumber daya manusia serta sumber-sumber lain. Manajemen ialah wadah didalam ilmu pengetahuan, sehingga manajemen bisa dibuktikan secara umum kebenarannya.

2.   Ricky W. Griffin

Manajemen adalah sebuah proses perencanaan, pengorganisasian, pengkoordinasian, dan pengontrolan sumber daya untuk mencapai sasaran secara efektif dan efisien. Efektif berarti bahwa tujuan dapat dicapai sesuai dengan perencanaan, sementara efisien berarti bahwa tugas yang ada dilaksanakan secara benar, terorganisir, dan sesuai dengan jadwal.

Dari pengertian menurut 2 ahli tersebut dapat disimpulkan bahwa manajemen merupakan suatu proses yang terdiri dari perencanaan, pengorganisasian dan pengontrolan untuk mencapai suatu tujuan.

B.  Proyek

Ada beberapa pengertian manajemen menurut para ahli. Berikut ini pengertian manajemen menurut para ahli :

1.   Nurhayati (2010:4)

Proyek adalah upaya atau aktivitas yang diorganisasikan untuk mencapai tujuan, sasaran dan harapan-harapan penting dengan menggunakan anggaran dana serta sumber daya yang tersedia, yang harus diselesaikan dalam jangka waktu tertentu.

2.   PMBOK (Project Management Body of Knowledge) Edisi ke-3

Proyek adalah usaha sementara dengan awal dan akhir dan harus digunakan untuk menciptakan produk, layanan atau hasil yang unik.

Dari pengertian menurut 2 ahli tersebut dapat disimpulkan bahwa proyek adalah suatu aktivitas sementara untuk mencapai suatu tujuan.

C.  Perangkat lunak

Sama seperti manajemen dan proyek, perangkat lunak mempunyai pengertian menurut para ahli. Berikut ini pengertian menurut para ahli :

1.   Imam Prayogo Pujiono

Ahli yang mendefinisikan software adalah Imam Prayogo Pujiono, M.kom yang merupakan praktisi dan dosen di dalam bidang rekayasa perangkat lunak. Imam berpendapat bahwa software adalah sebuah program dalam komputer yang dirancang sedemikian rupa, yang seandainya dijalankan akan memberikan perintah ke komputer / hardware / software lain dalam rangka menyelesaikan sebuah tugas, pekerjaan, dan juga tuntutan tertentu seperti yang diharapkan user.

2.   Fauziah

Ahli lainnya yang mendefinisikan software adalah Fauziya, menurut Fauziyah software adalah sebuah program komputer yang berguna untuk menginput data, menyimpan data, mengecek data, memanipulasi data dan memperoleh hasil dari data tersebut. yang dilakukan dengan menggunakan perangkat hardware.

Dari pengertian menurut 2 ahli tersebut dapat disimpulkan bahwa perangkat lunak adalah suatu program komputer yang dirancang untuk menginput data, menyimpan data dan lainnya yang berkaitan dengan komputer tersebut dengan menggunakan perangkat keras (hardware).

Setelah kita mengetahui apa itu manajemen, proyek dan perangkat lunak, mari kita mengetahui apa itu manajemen proyek perangkat lunak dapat kita simpulkan bahwa manajemen proyek perangkat lunak merupakan sebuah proses perencanaan, pengorganisasian dan pengontrolan program komputer yang beraktivitas sementara.

PERMASALAHAN YANG TERJADI DALAM MENGERJAKAN PROYEK PERANGKAT LUNAK

Ada beberapa permasalahan yang sering sekali terjadi dalam mengerjekan proyek perangkat lunak menurut salah satu sumber eksternal yaitu :

1.   Poor User Input

User kurang terbuka dalam menyatakan kebutuhannya, padahal hal itu sangat berdampak pada pekerjaan software developer. Akibatnya, pihak developer harus bekerja keras untuk memahami apa saja yang menjadi bisnis user, sehingga bisa memprediksi fasilitas apa saja yang diperlukan.

2.   Stakeholder Conflichts

Stakeholder bekerja di bawah ilusi bahwa semua orang harus mendapatkan apa yang mereka inginkan. Akibatnya sejumlah alternatif yang berbeda dipersiapkan untuk mengakomodasi semua permintaan yang mungkin timbul. Perbedaan tersebut selanjutnya diekspos oleh developer dan mengakibatkan sistem menjadi ambigu. Konflik dalam stakeholder ini bisa menjadi tokoh utama kegagalan sebuah proyek, karena pihak developer tidak dapat memahami apa yang sesungguhnya diinginkan oleh stakeholder.  

3.   Vague Requirement

Perlu bekerja keras untuk mempelajari apa yang akan terjadi ketika sebuah proyek mulai dikerjakan pada saat kebutuhan yang diinginkan belum jelas. Bisa jadi untuk setiap step yang diambil kemudian perlu mundur tiga langkah ke belakang. Biaya proyek dan kualitas hasil yang berubah cepat bisa lepas dari kontrol, sehingga perusahaan bisa dipersalahkan bahkan bisa kehilangan kontrak untuk menyelesaikan proyek tersebut.Seperti yang sering terjadi pada sejumlah proyek gagal, bahwa lingkup permasalahan yang tidak cukup sempit tidak bisa memberi peluang yang masuk akal untuk sukses. Oleh karenanya perlu memastikan kebutuhan yang diinginkan user sebelum pekerjaan tersebut dimulai. Kendati demikian, kenyataannya perkembangan kebutuhan masih saja terjadi. Permasalahan ini bisa diatasi bila arsitektur dan prosesnya dibuat mampu mengakomodasi perubahan atau setidaknya dibuat ketentuan jelas bagaimana dan kapan requirement bisa ditambahkan, dilepas dan diimplementasikan, termasuk siapa yang akan menanggung biaya perubahan tersebut. 

4.   Poor Cost and Schedule Estimation 

Sebenarnya tidak fair menuduh setiap proyek PL pasti mengalami kegagalan, jika tidak mengaitkan antara biaya yang dikeluarkan dengan tujuan yang diinginkan. Sama seperti yang lain, setiap proyek PL juga memiliki jadwal dan biaya minimal yang dapat dicapai. Permasalahan bisa muncul kapan saja manakala orang  yang membuat jadwal tidak mendengarkan masukan orang yang biasa mengerjakannya. Misalnya untuk menyelesaikan sebuah program biasanya diperlukan 5 orang selama setahun, jelas berbeda seandainya hanya dikerjakan 4 orang selama 8 bulan, baik dilihat dari sisi desain maupun quality-check-nya.   

5.   Skills That Do Not Match The Job

Pengerjaan proyek dengan teknologi tinggi memerlukan seorang manajer dengan kemampuan teknik yang hebat. Penanggung jawab proyek harus bisa menempatkan orang yang memahami dampak dari resiko teknik yang diambil. Namun demikian, seorang teknolog yang baik tidak perlu diseimbangkan dengan manager yang baik, karena kemampuan manajemen dan pemrograman tidak bisa dipertukarkan.Pada proyek yang lebih besar membutuhkan orang-orang yang cakap dalam planning, oversight, organization dan communication skill; sementara seorang teknolog yang brilian tidak perlu memiliki keahlian tersebut.Sebuah team yang beranggotakan orang-orang dengan gaji lebih besar namun memiliki kemampuan spesialisasi yang baik, akan lebih pantas dipilih daripada sebuah kelompok yang terdiri dari orang-orang dengan gaji rendah yang masih memerlukan berminggu-minggu bahkan berbulan-bulan untuk mempelajari sebuah proses atau teknologi baru sebelum mereka mulai mengerjakannya. 

6.   Hidden Cost of  Going “Lean and Mean”

Sejumlah kegagalan akan dipandang sebagai hasil langsung dari kinerja yang buruk, meskipun sesungguhnya kinerja yang buruk tidak menunjuk pada faktor yang signifikan dalam kegagalan pada kebanyakan proyek. Kegagalan sebuah proyek tidak bisa terlepas dari rencana tujuan yang ingin dicapai.  Hal lain yang juga pantas dicermati adanya perbedaan kecenderungan yang terjadi dalam sebuah organisasi. Pada level yang lebih rendah, seorang developer akan sibuk menghitung pengeluaran mereka yang mahal, hasil kerja pegawai, update software dan pekerjaan-pekerjaan lainnya, sedangkan pada tingkatan yang lebih tinggi hal tersebut akan dikerjakan oleh seorang spesialis yang memadai. Kebanyakan software developer akan menghabiskan setengah dari jam kerja mereka untuk berlama-lama dalam mengerjakan tugas yang diberikan dengan tanpa melakukan apapun terhadap pekerjaan tersebut. Orang-orang demikian ini sangat tidak berkemampuan dan menjadi isu produktifitas yang sangat serius. 

7.   Failure to Plan

Banyak orang bekerja keras, tapi tak seorangpun yang memiliki rencana, karena tidak ada yang merasa perlu membuat rencana. Seorang manajer proyek sering tidak membuat rencana, karena banyak rencana yang diserahkan bersamaan dengan berlalunya waktu.  Mereka mengira waktunya akan habis untuk melakukan hal-hal seperti planning, design, requirement dan inspection.   Kebanyakan dari mereka berpendapat bahwa hal-hal tersebut bisa dilakukan bersamaan dengan pekerjaan sesungguhnya, seperti pada saat coding dan testing. Pandangan ini umumnya datang dari kalangan programmer yang mengisukan bahwa hal tersebut dapat dilakukan ketika perangkat lunak diimplementasikan, padahal jelas ada perbedaan antara speed dan progress. Kita perlu memberi penghargaan pada orang-orang yang tidak menganut pandangan itu sehingga terlepas dari misi bunuh diri tersebut. 

8.   Communication Breakdown

Sejumlah problema yang timbul pada proyek berskala besar biasanya jika orang yang mengerjakannya berasal dari bagian yang berbeda. Dalam banyak kasus proyek yang bermasalah, tidak ada seorang pun yang memiliki pandangan yang menyeluruh pada proyek tersebut, khususnya bila proyeknya berskala besar. Untuk itu perlu kiranya menginvestasikan waktu tambahan secara periodik agar semua orang di setiap posisi bersedia mempelajari gambaran besar proyek tersebut. Hal ini sejalan dengan sementara orang yang berpendapat bahwa seorang yang mengerjakan kepingan-kepingan kecil sebuah puzzle perlu mengetahui bagaimana sebuah keping bisa masuk ke dalam arsitektur gambar keseluruhan.   

9.   Poor Architecture

Desain perangkat lunak sebaiknya dapat dikonfigurasi ulang untuk mendukung sebuah fungsi baru. Sebuah arsitektur PL seharusnya bisa mengikuti organisasi dan misi yang berubah, setidaknya harus memperhitungkan keterbatasan jangka panjang, tingkat kesulitan dan harganya. Arsitektur PL harus dipandang seperti bangunan rumah, dimana penambahan pipa dan kabel  harus bisa dilakukan untuk fasilitas yang belum terpikirkan sebelumnya. Begitupun ketika sebuah PL mengalami perubahan kebutuhan atau bisnis yang tidak diantisipasi sebelumnya, harus dapat ditambah atau dimodifikasi tanpa harus membuat PL yang baru. 

10. Late Failure Warning Signals

Lamanya waktu penyelesaian dan besarnya biaya pembuatan PL sangat dipengaruhi oleh  sinyalemen orang yang mana kita takut mengatakan “tidak” kepadanya. Kedengarannya hal ini tidak baik secara politik dikarenakan  mengatakan atau menunjukkan perkiraan yang jauh dari yang dapat dijalankan. Memang kenyataannya tak seorangpun bisa mengetahui bencana yang mendekat karena sering kali tak terlihat gejala awalnya. Dalam dunia nyata, sama seperti orang yang levelnya lebih rendah dapat meyakinkan manajer level atasnya bahwa proyek tersebut sesungguhnya tidak dapat dikerjakan sedemikian rupa hingga jatuh kepadanya.

Dari penjelasan tentang permasalahan tersebut, dapat disimpulkan bahwa mengerjakan proyek perangkat lunak banyak sekali permasalahannya, mulai dari user yang kurang terbuka sampai permasalahan yang berkaitan dengan waktu, waktu memang merupakan suatu hal yang pasti dalam permasalahan ini.

Ada sebuah pertanyaan yang sering sekali dipertanyakan yaitu “mengapa mengerjakan sebuah proyek perangkat lunak jauh lebih bermasalah dibandingkan dengan mengerjakan proyek rekayasa lainnya?”. Dengan pertanyaan tersebut sudah terlihat jelaskan bahwa permasalahan saat mengerjakan sebuah proyek perangkat lunak jauh lebih bermasalah. Kita sudah mengetahui banyak sekali permasalahannya dari bagian yang sudah diperjelaskan di atas. Banyak sekali permasalahan yang tidak bisa diselesaikan dengan cepat dibandingkan dengan mengerjakan proyek rekayasa lainnya.

Referensi

• https://www.zonareferensi.com/pengertian-manajemen/
• https://ilmumanajemenindustri.com/pengertian-manajemen-proyek-project-management-karakteristik-manajemen-proyek/
• http://www.materidosen.com/2017/03/9-pengertian-software-menurut-para-ahli.html
• https://yayuk05.wordpress.com/2007/10/01/faktor-faktor-penyebab-kegagalan-proyek-perangkat-lunak/

Perancangan Basis Data 5 || ERD (Entity Relationship Diagram)

A.  Pengertian

Diagram Hubungan Entitas atau yang biasa dikenal dengan sebutan ERD (Entitiy Relationship Diagram) merupakan suatu konsep atau pemodelan dari basis data yang terdiri dari sekumpulan objek (entity) dan hubungan (relationship) antara objek yang satu dengan yang lainnya yang dikonversikan ke dalam bentuk diagram atau yang sering di kenal dengan sebutan flowchart. ERD mempunyai peranan yang sangat penting di dalam suatu proses pembuatan database yaitu dengan ERD yang di dalamnya sudah terdapat penjelasan tentang alur pemrosesan suatu data, mulai dari proses input sampai outputnya dan dengan ERD juga kita dapat menguji model dengan mengabaikan proses yang harus dilakukan.

B.  Komponen – Komponen

Ada 3 komponen yang akan dibentuk dalam pembentukan ERD, yaitu :

1.     Entitas

Entitas adalah suatu objek atau tempat yang dapat diidentifikasikan secara unik yang berisi beberapa atribut yang dimana semua informasi atau inti yang berkaitan dengannya dikumpulkan mulai dari entitas yang satu ke entitas yang lainnya yang berfungsi untuk memberikan identitas pada entitas yang memiliki label dan nama. Contoh : Mahasiswa, Kartu Anggota Perpustakaan (KAP), dan Buku.

Entitas dilambangkan dengan simbol yang berbentuk persegi panjang. Berikut ini merupakan simbol entitas :

2.     Relasi

Relasi adalah suatu hubungan antara entitas yang satu dengan entitas yang lainnya yang tidak mempunyai fisik tetapi hanya sebagai konseptual yang berfungsi untuk mengetahui jenis hubungan yang ada pada 2 file atau entitas. Contoh : Mahasiswa mendaftar sebagai anggota perpustakaan (KAP), relasinya yaitu mendaftar.

Relasi dilambangkan dengan simbol yang berbentuk belah ketupat. Berikut ini merupakan simbol relasi :

3.      Atribut

Atribut adalah suatu karakteristik dari entitas maupun relasi yang menyediakan penjelasan detail tentang entitas maupun relasi tersebut yang berfungsi untuk memperjelas atribut yang dimiliki oleh sebuah entitas. Atribut mempunyai struktur internal yang berupa tipe data.

Atribut dilambangkan dengan simbol yang berbentuk lingkaran atau elips. Berikut ini merupakan simbol atribut :

Atribut mempunyai beberapa jenis yakni :

a.      Atribut Key

Atribut key adalah satu atau sebuah gabungan dari beberapa atribut yang dapat membedakan semua baris data (Row/Record ) dalam tabel secara unik. Dikatakan unik jika pada atribut yang dijadikan key tidak boleh ada baris data dengan nilai yang sama. Contoh : Nomor Pokok Mahasiswa (NPM), NIM, dan nomor pokok lainnya.

b.     Atribut simple

Atribut yang bernilai atomik atau tidak dapat dipecah/dipilah lagi. Contoh : Alamat, penerbit, tahun terbit, judul buku.

c.      Atribut Multivalue

Nilai dari suatu atribut yang mempunyai lebih dari satu nilai dari atribut yang bersangkutan. Contoh : pada sebuah buku terdapat beberapa pengarang.

d.     Atribut Composite

Atribut composite adalah suatu atribut yang terdiri dari beberapa atribut yang lebih kecil yang mempunyai arti tertent atau mempunyai sub attribute. Contoh : entitas nama yaitu nama depan, nama tengah, dan nama belakang.

e.      Atribut Derivatif

Atribut yang tidak harus disimpan dalam database Ex. Total. atau atribut yang dihasilkan dari atribut lain atau dari suatu relationship. Atribut ini dilambangkan dengan bentuk oval yang bergaris putus-putus.

4.     Alur

Alur berfungsi untuk menghubungkan atribut dengan entitas dan entitas dengan relasi. Alur dilambangkan dengan simbol yang berbentuk garis. Berikut ini merupakan simbol alur :

C.  Derajat Relasi

1.     Unary (Derajat Satu)

Unary adalah satu buah relasi yang menghubungkan satu buah entitas.

Contoh:

2.     Binary (Derajat Dua)

Binary adalah satu buah relasi yang menghubungkan dua buah entitas.

Contoh:

3.     Ternary (Derajat Tiga)

Ternary adalah satu buah relasi yang menghubungkan tiga buah entitas.

Contoh:

D.  Hubungan Relasi/Kardinalitas

Beberapa tabel yang berada di basis data setidaknya memiliki hubungan yang berkaitan untuk menghasilkan kriteria informasi yang diharapkan. Berikut ini adalah jenis-jenis hubungan relasi berdasarkan dari hubungan antar entitas atau tabel, yaitu :

1.     One to One (1:1)

One to One adalah perbandingan antara entitas pertama dengan entitas kedua (satu banding satu).

Contoh :

2.     One to Many (1:M)

One to Many adalah perbandingan antara entitas pertama dengan entitas kedua (satu banding banyak).

Contoh:

3.     Many to One(M:1)

Many to One adalah perbandingan antara entitas pertama dengan entitas kedua (banyak banding satu).

Contoh:

4.     Many to Many (M:M)

Many to Many yaitu perbandingan antara entitas pertama dengan entitas kedua (banyak banding banyak).

Contoh:

Referensi :

1. http://www.academia.edu/34651199/MAKALAH_ENTITY_RELATIONSHIP_DIAGRAM_ERD_

2. http://apriliyatiwen.blogspot.com/2013/02/erd-entity-relationship-diagram.html

3. https://inuuard.wordpress.com/2014/07/18/pengertian-dan-simbol-simbol-entity-relational-diagram-erd/ 

Perancangan Basis Data 4 || Abstraksi Data, Struktur & Model Basis Data

Assalamualaikum Wr. Wb.

Pada postingan saya kali ini, saya akan membahas tentang abstraksi data, struktur dan model basis data serta apa itu degree dan kardinalitas.

ABSTRAKSI DATA YANG DIGAMBARKAN PADA ARSITEKTUR DBMS

Abstraksi data adalah tingkatan – tingkatan atau level – level dalam melihat bagaimana data dalam sebuah sistem basis data sehingga data tersebut menyerupai kondisi yang sebenarnya dihadapi oleh pengguna sehari - hari.

Sistem menyembunyikan detail tentang bagaimana sebuah data disimpan dan dipelihara. Karena itu seringkali data yang terlihat oleh user sebelumnya berbeda dengan data yang tersimpan secara fisik.

Ada 3 tingkatan atau level dalam abstraksi, yaitu :

1.    Level Pandangan Pemakai (User View)

Level pandangan pemakai atau level eksternal merupakan level atau tingkatan tertinggi dalam abstraksi data yang hanya menunjukkan sebagian saja yang dilihat dan dipakai dari keseluruhan basis data. Pada level ini pemakai hanya bisa melihat struktur data sesuai dengan kebutuhan sehingga setiap pemakai bisa memiliki pandangan yang berbeda dari pemakai lainnya dan tidak semua pemakai membutuhkan semua data dalam basis data.

2.    Level Konseptual (Conceptual)

Level konseptual atau level logika ini menggambarkan data yang disimpan dalam basis data dan menjelaskan hubungan relasi yang terjadi antar data dari keseluruhan basis data yang penggambarannya cukup dengan memakai kotak, garis dan hubungan secukupnya. Level ini berisi struktur logik basis data yang hanya dapat dilihat oleh seorang Database Administrator (DBA).

Hal-hal yang digambarkan dalam tingkat konseptual adalah:

a. Entitas, atribut dan relasinya

b. Konstrain – konstrain terhadap data

c. Informasi semantiks data

d. Informasi keamanan dan integritas data

3.    Level Fisik (Physical)

Level fisik atau level internal ini merupakan level yang paling rendah dalam abstraksi data yang representasi dari organisasi data disimpan secara fisik dalam bentuk kode, teks, angka atau himpunan dan bit data.

Tingkat internal memperhatikan hal-hal berikut ini:

a. Alokasi ruang penyimpana untuk data dan indeks

b. Deskripsi record untuk penyimpanan

c. Penempatan record data

d. Teknik kompresi dan enkripsi data

STRUKTUR / KONSEP BASIS DATA

Characters adalah bagian data terkecil yang berupa angka, huruf, atau karakter khusus yang membentuk sebuah item data atau field.

Field/item adalah representasi suatu atribut dan record (rekaman/tupel) yang sejenis yang menunjukkan suatu item dari data.

Record/rekaman/tupel adalah kumpulan data yang terdiri dari satu atau lebih suatu field yang membentuk suatu record atau rekaman.

File adalah kumpulan dari record - record yang menggambarkan satu kesatuan data yang sejenis.

Database adalah kumpulan dari file atau tabel yang membentuk suatu database.

MODEL BASIS DATA RELASIONAL

Sebelum saya menjelaskan tentang model relasional, terlebih dahulu saya akan menjelaskan sedikit apa – apa saja model basis data tersebut selain model relasional.

Ada 2 model basis data selain model relasional, yaitu :

1.    Model Hierarkis

Model hierarkis merupakan model yang sering dijabarkan dalam bentuk pohon terbalik. Mengapa dijabarkan dalam bentuk pohon terbalik?. Karena model ini diibaratkan seperti orang tua (parent – record) dan anak (child – record), dimana setiap anak hanya bisa memiliki atau mempunyai satu orang tua, sedangkan orang tua dapat memiliki atau mempunyai sejumlah anak.

2.    Model Jaringan (network)

Model data jaringan adalah pengembangan dari model data heirarkis. Pada model data ini diperkenalkan bahwa sebuah child – record bisa memiliki lebih dari satu parent – record. Jadi antara parent – record dan child – record diperlukan penghubung (link atau pointer) yang bisa satu arah atau dua arah.

Mengingat bahwa anak bisa memiliki lebih dari sebuah orang tua, maka model data ini mendukung hubungan Many To Many (M:M).

Selanjutnya saya akan menjelaskan tentang model relasional.

Model relasional adalah model basis data yang paling popular dan paling banyak digunakan sekarang ini yang merupakan suatu model basis data yang menggunakan tabel dua dimensi, yang terdiri atas baris dan kolom untuk menggambarkan sebuah berkas data yang dimana tabel dapat berhubungan dengan tabel yang lain dengan menggunakan kunci.

Cara kerja dari model relasional yaitu elemen – elemen data disimpan dalam tabel lain yang membentuk baris dan kolom. Dalam model ini data diatur secara logis yang dimana berdasarkan isi data. Masing-masing record dalam tabel diidentifikasi oleh sebuah field/kunci primer yang berisi sebuah nilai unik. Karena itulah data dalam model relasional dapat muncul dengan cara yang berbeda dari cara ia disimpan secara fisik pada komputer dimana pengguna tidak mengetahui lokasi fisik sebuah record untuk mendapatkan kembali datanya.

Kelebihan model relasional :
·   Data sangat cepat diakses
·   Bentuk modelnya yang sederhana dibandingkan dengan model jaringan dan hierarkis
·   Struktur basis data mudah dilakukan perubahan
·   Data direpresentasikan secara logik, user tidak membutuhkan bagaimana data disimpan.
·   Mudah untuk membentuk atau melakukan berbagai operasi data.
·   Mudah untuk mengimplementasikan integritas data
·   Data lebih akurat
·   Mudah untuk membangun dan memodifikasi program aplikasi
·   Telah dikembangkan Structure Query Language (SQL).

Kelemahan model relasional :

·   Kelompok informasi/tables yang berbeda harus dilakukan joined untuk melakukan retrieve data

·   User harus familiar dengan relasi antar tabel

·   User harus belajar SQL

DEGREE DAN KARDINALITAS

Degree

Degree merupakan jumlah atau banyaknya atribut/kolom dalam sebuah relasi/tabel.

Kardinalitas

Kardinalitas merupakan jumlah atau banyaknya tupel/baris dalam sebuah relasi/tabel. Kardinalitas dari relasi ini dapat berubah – ubah sesuai dengan perubahan yang terjadi pada relasi.

Mungkin ini saja pembahasan tentang abstraksi data, struktur dan model basis data beserta pengertian dari degree dan kardinalitas..

Wassalamualaikum Wr. Wb.

Referensi :

https://id.wikipedia.org/wiki/Pangkalan_data

https://www.academia.edu/11881427/MODEL_BASIS_DATA_RELASIONAL_JARINGAN_DAN_HIERARKI