რა არის მონაცემთა ბაზა? სახელმძღვანელო აპლიკაციების შემქმნელთათვის
მონაცემთა ბაზა არის ორგანიზებული საცავი, სადაც აპლიკაცია ინახავს და საიდანაც კითხულობს ინფორმაციას: თავის მომხმარებლებს, შეკვეთებს, დაჯავშნებს, შეტყობინებებს. ბრაუზერის ჩანართში დაცული ინფორმაციისგან განსხვავებით, მონაცემთა ბაზაში არსებული მონაცემები გვერდის გადატვირთვის ან სერვერის გადატვირთვის შემდეგაც რჩება, და ყველა, ვინც აპლიკაციას იყენებს, ერთსა და იმავე ჩანაწერებს ხედავს. მონაცემთა უმეტესობა ცხრილებად ორგანიზდება, მსგავსად ელექტრონული ცხრილის ფურცლებისა, მაგრამ მკაცრი წესებით, რომლებიც მონაცემებს თანმიმდევრულად ინახავს.
რატომ არის მნიშვნელოვანი AI-ით აშენებისას
AI-ით მომუშავე ადამიანების ყველაზე გავრცელებული სიურპრიზი არის აპლიკაცია, რომელიც დასრულებულად გამოიყურება, მაგრამ ყველაფერს ივიწყებს. მომხმარებელს ამატებთ, გვერდს ანახლებთ და ის ქრება. ეს ჩვეულებრივ იმას ნიშნავს, რომ აპლიკაცია მონაცემებს ბრაუზერის მეხსიერებაში ინახავდა და არა მონაცემთა ბაზაში.
მონაცემთა ბაზა ასევე ბევრ მნიშვნელოვან გადაწყვეტილებას ინახავს, იმისდა მიუხედავად, ამას აცნობიერებთ თუ არა:
- რას ჩაწერთ. თუ დაჯავშნის სტატუსს არ ინახავთ, ვერ აჩვენებთ, რომელი დაჯავშნები გაუქმდა.
- როგორ უკავშირდება ყველაფერი ერთმანეთს. აქვს თუ არა ერთ მომხმარებელს ბევრი დაჯავშნა, ან ერთ დაჯავშნას ბევრი სერვისი, მთელ აპლიკაციას აყალიბებს.
- ვის რა უნდა ნახოს. კონფიდენციალურობის უმეტესი შეცდომები იმაზეა, თუ რომელი ჩანაწერის წაკითხვა შეუძლია მომხმარებელს.
მონაცემთა ბაზის დიზაინი თქვენ არ გჭირდებათ, მაგრამ მისი საფუძვლების ცოდნა გეხმარებათ, მონაცემები ნათლად აღწეროთ და პრობლემები ადრე დაინახოთ.
ყოველდღიური ანალოგია
წარმოიდგინეთ კარგად ორგანიზებული საოფისე კარადა პატარა ოფისში.
თითოეულ უჯრაში ერთი სახის რამ ინახება: ერთში კლიენტები, მეორეში შეხვედრები, მესამეში ინვოისები. თითოეულ უჯრაში ყველა საქაღალდეს ერთნაირი ფორმატი აქვს და ერთნაირი ველებია შევსებული. თითოეულ საქაღალდეს უნიკალური ნომერი აქვს, და როცა ინვოისი კლიენტს ეკუთვნის, ინვოისის საქაღალდეში არ კოპირდება კლიენტის მთელი ფაილი, არამედ იწერება მისი ნომერი.
ეს არის რელაციური მონაცემთა ბაზა. უჯრები არის ცხრილები, საქაღალდეები არის ხაზები, ველები არის სვეტები, უნიკალური ნომრები არის პირველადი გასაღებები (primary keys), ხოლო სხვა საქაღალდეზე მითითება არის გარე გასაღები (foreign key). კარგი ოფისის მენეჯერი წესებსაც ახორციელებს, მაგალითად: შეხვედრას თარიღის გარეშე არ ვწერთ, ორ კლიენტს ერთი ნომერი არ აქვს. მონაცემთა ბაზაც ასე მუშაობს.
სამუშაო მაგალითი: სალონის დაჯავშნის აპლიკაცია
ვთქვათ, AI-ს სთხოვთ, შეუკვეთოთ დაჯავშნის საიტი თმის სალონისთვის. კარგი მონაცემთა ბაზა ოთხ ცხრილს ექნებოდა.
services
| id | name | duration_minutes | price |
|---|---|---|---|
| 1 | თმის შეჭრა | 45 | 40.00 |
| 2 | შეღებვა | 90 | 95.00 |
staff
| id | name | |
|---|---|---|
| 1 | სარა | sara@example.com |
| 2 | ომარი | omar@example.com |
customers
| id | name | phone | |
|---|---|---|---|
| 101 | ლენა პარკი | lena@example.com | 555-0100 |
bookings
| id | customer_id | service_id | staff_id | starts_at | status |
|---|---|---|---|---|---|
| 5001 | 101 | 1 | 2 | 2026-10-03 14:00 | confirmed |
გაითვალისწინეთ bookings ცხრილი. ის ლენას სახელსა და ტელეფონის ნომერს ყოველ დაჯავშნაში არ აკოპირებს. ის ინახავს customer_id = 101-ს. თუ ლენა ტელეფონის ნომერს შეცვლის, ის ერთ ადგილას შეიცვლება, და ყველა დაჯავშნა ახალ ნომერს აჩვენებს. ეს არის რელაციური მონაცემთა ბაზის მთავარი იდეა: ყოველი ფაქტი ერთხელ ინახება, და მასზე მითითება ხდება.
იგივე სტრუქტურა სასარგებლო კითხვებზეც პასუხობს:
- «რომელი დროებია თავისუფალი ომარისთვის პარასკევს?» — ვამოწმებთ ომარის დაჯავშნებს იმ დღისთვის.
- «რამდენი შემოსავალი მოიტანა შეღებვის მომსახურებამ ამ თვეში?» — ვაერთიანებთ დაჯავშნებს სერვისებთან და ფასებს ვჯამავთ.
- «რომელმა კლიენტებმა 90 დღის განმავლობაში არ დაჯავშნეს?» — ვადარებთ კლიენტებს მათ ბოლო დაჯავშნასთან.
მთავარი ტერმინები
| ტერმინი | რას ნიშნავს |
|---|---|
| Table (ცხრილი) | ერთი სახის ჩანაწერების კრებული, მაგალითად კლიენტები ან დაჯავშნები. |
| Row (ხაზი, ჩანაწერი) | ცხრილის ერთი ელემენტი: ერთი კლიენტი, ერთი დაჯავშნა. |
| Column (სვეტი, ველი) | ინფორმაციის ერთი ნაწილი, რომელიც ყველა ხაზს აქვს, მაგალითად ელფოსტა ან ფასი. |
| Primary key (პირველადი გასაღები) | უნიკალური ID ყოველი ხაზისთვის, ჩვეულებრივ რიცხვი ან შემთხვევითი სტრიქონი. |
| Foreign key (გარე გასაღები) | სვეტი, რომელიც სხვა ცხრილის ხაზზე მიუთითებს, მაგალითად customer_id დაჯავშნებში. |
| Schema (სქემა) | მთლიანი დიზაინი: რომელი ცხრილები არსებობს, მათი სვეტები და როგორ უკავშირდებიან. |
| Query (მოთხოვნა) | მოთხოვნა მონაცემების წასაკითხად ან შესაცვლელად, მაგალითად «ხვალინდელი ყველა დაჯავშნა». |
| SQL | Structured Query Language, რელაციურ მონაცემთა ბაზებში მოთხოვნების სტანდარტული ენა. |
| Migration (მიგრაცია) | შენახული, გამეორებადი ცვლილება სქემაში, მაგალითად ახალი სვეტის დამატება. |
| Index (ინდექსი) | საძიებო სტრუქტურა, რომელიც სვეტზე ძიებას აჩქარებს, წიგნის საძიებლის მსგავსად. |
| CRUD | Create, Read, Update, Delete: ოთხი ძირითადი მოქმედება, რაც აპლიკაციებს მონაცემებთან აქვთ. |
| Backup (სარეზერვო ასლი) | მონაცემების ასლი, რომლის აღდგენაც შეგიძლიათ, თუ რამე არასწორად წავა. |
მონაცემთა ბაზების ტიპები
| ტიპი | როგორ ინახავს მონაცემებს | მაგალითები | კარგად გამოდგება |
|---|---|---|---|
| რელაციური (SQL) | ცხრილები ფიქსირებული სვეტებით და მათ შორის კავშირებით | Postgres, MySQL, SQLite | უმეტესი ბიზნეს აპლიკაციებისთვის: დაჯავშნები, მაღაზიები, CRM, SaaS |
| დოკუმენტური (NoSQL) | მოქნილი JSON-ის მსგავსი დოკუმენტები | MongoDB, Firestore | მონაცემებისთვის, რომელთა სტრუქტურა ჩანაწერებს შორის ძალიან განსხვავდება |
| Key-value (გასაღები-მნიშვნელობა) | მნიშვნელობა შენახულია გასაღების ქვეშ | Redis | ქეშირებისთვის, მოკლევადიანი მონაცემებისთვის, მაგალითად სესიებისთვის |
თითქმის ყველაფრისთვის, რასაც მეწარმე ან მცირე ბიზნესი ჯერ აშენებს, რელაციური მონაცემთა ბაზა უსაფრთხო ნაგულისხმევი არჩევანია.
სად ცხოვრობს მონაცემთა ბაზა თქვენს აპლიკაციაში
ვიზიტორები მონაცემთა ბაზასთან პირდაპირ არ ურთიერთობენ. მათ ბრაუზერში არსებული გვერდი (frontend) მონაცემებს თქვენს სერვერს (backend) სთხოვს, ჩვეულებრივ API-ის მეშვეობით. სერვერი ამოწმებს, ვინ იკითხავს და აქვს თუ არა ამის უფლება, შემდეგ მონაცემთა ბაზას უგზავნის მოთხოვნას და პასუხად მხოლოდ იმას აბრუნებს, რის ნახვაც ამ ადამიანს შეუძლია.
ეს შუალედური ნაბიჯი მნიშვნელოვანია. თუ ბრაუზერს მონაცემთა ბაზასთან სრული წვდომით პირდაპირ შეეძლებოდა მუშაობა, ნებისმიერს შეეძლო დეველოპერულ ხელსაწყოებში შესვლით ყველაფერი ენახა.
გავრცელებული შეცდომები და მცდარი წარმოდგენები
- მონაცემების მხოლოდ ბრაუზერში შენახვა. ბრაუზერის საცავი (მაგალითად localStorage) ერთ მოწყობილობასა და ერთ ბრაუზერში რჩება. ის კარგია დამახსოვრებული ფილტრისთვის, მაგრამ არა შეკვეთებისთვის.
- ყველაფრის ერთ ცხრილში თავმოყრა. ერთი «დაჯავშნების» ცხრილი, სადაც კლიენტის სახელი, ტელეფონი და სერვისის ფასი ყოველ ხაზში კოპირდება, მალე გაუსინქრონდება.
- პაროლების ტექსტურად შენახვა. პაროლები ჰეშირებული უნდა იყოს და არასდროს წაკითხვადი სახით. იხილეთ რა არის ავთენტიფიკაცია.
- წესების გარეშე. თუ სავალდებულო ველებსა და უნიკალურობის წესებს არ აწესებთ, მიიღებთ დაჯავშნებს თარიღის გარეშე და დუბლირებულ კლიენტებს.
- წაშლის დაგეგმვის დავიწყება. გადაწყვიტეთ, კლიენტის წაშლისას მისი დაჯავშნებიც წაიშლება, შენარჩუნდება თუ აიკრძალება.
- წარმოების მონაცემებზე ექსპერიმენტი. რისკიანი ცვლილებები ჯერ უსაფრთხო ადგილას გამოსცადეთ და სარეზერვო ასლები შეინახეთ.
- სპრედშიტის სამუდამოდ მონაცემთა ბაზად მიჩნევა. ცხრილები კარგია დასაწყისისთვის, მაგრამ ბევრ ერთდროულ მომხმარებელთან და უფლებებთან მათ გაძნელება უჭირთ. იხილეთ როგორ გადავაქციოთ ცხრილი აპლიკაციად.
რა ვკითხოთ თქვენს AI შემქმნელს
- «შეინახე ეს მონაცემთა ბაზაში და არა ბრაუზერში. მითხარი, რომელ ცხრილებს შექმნი.»
- «მაჩვენე სქემა მარტივი ცხრილის სახით: თითოეული ცხრილი, მისი სვეტები და როგორ უკავშირდებიან.»
- «კლიენტს შეიძლება ჰქონდეს ბევრი დაჯავშნა; თითოეულ დაჯავშნას ზუსტად ერთი სერვისი და ერთი თანამშრომელი აქვს.»
- «გახადე კლიენტის ელფოსტა სავალდებულო და უნიკალური.»
- «შეაჩერე ორი დაჯავშნა, რომელიც ერთ თანამშრომელთან ემთხვევა.»
- «ავტორიზებულმა მფლობელმა მხოლოდ შეიძლება ყველა დაჯავშნა ნახოს; კლიენტებმა მხოლოდ საკუთარი. ეს სერვერზე აღასრულე.»
- «სერვისის წაშლისას წარსული დაჯავშნები არ წაიშალოს, არამედ სერვისი არააქტიურად აღინიშნოს.»
მონაცემთა ბაზები Mythex-ში
როცა თქვენს აპლიკაციას მონაცემების შენახვა სჭირდება, Mythex პროექტში გამოყოფილ Postgres მონაცემთა ბაზას ამატებს. ამის მოთხოვნა შეგიძლიათ ჩატში («შეინახე ლოდინის სიის რეგისტრაციები მონაცემთა ბაზაში») ან /database ბრძანებით. კავშირის დეტალები აპლიკაციას ავტომატურად გადაეცემა, ცხრილებს კი აგენტი ქმნის. მონაცემთა ბაზა უმოქმედობის ხუთი წუთის შემდეგ იძინებს და შემდეგი მოთხოვნისას იღვიძებს. გამოქვეყნებული გამოყენება იმ დროისთვის ირიცხება, რა დროსაც ის იყო ფხიზელი, იმავე კრედიტების ბალანსიდან, რომელსაც აშენებაც იყენებს. ის ხელმისაწვდომია Free და Pro გეგმებზე. დეტალები მოცემულია მონაცემთა ბაზის დოკუმენტაციაში, ხოლო აპლიკაციების შაბლონები მონაცემებზე დაფუძნებულ საწყის წერტილებს გთავაზობთ.
კითხვები
რა არის მონაცემთა ბაზა მარტივად რომ ვთქვათ?
მონაცემთა ბაზა არის ორგანიზებული საცავი, სადაც აპლიკაცია ინფორმაციას ინახავს და აქედან კითხულობს, მაგალითად მომხმარებლებს, შეკვეთებსა თუ დაჯავშნებს. ბრაუზერის ჩანართში მხოლოდ დროებით შენახული მონაცემებისგან განსხვავებით, ის გვერდის განახლების, გადატვირთვის ან სხვა მოწყობილობიდან შესვლის შემდეგაც რჩება.
Spreadsheet არის მონაცემთა ბაზა?
ცხრილს შეუძლია იგივე სახის მონაცემების შენახვა, მაგრამ ის აპლიკაციებისთვის არ არის შექმნილი. ნამდვილი მონაცემთა ბაზა ახდენს წესების აღსრულებას სვეტებში ჩასაწერ მნიშვნელობებზე, საიმედოდ აკავშირებს ცხრილებს, ემსახურება ერთდროულად ბევრ მწერალს და აკონტროლებს, ვის რა შეუძლია ნახვა.
რით განსხვავდება SQL და NoSQL მონაცემთა ბაზები?
SQL (რელაციური) მონაცემთა ბაზები, როგორიცაა Postgres და MySQL, მონაცემებს განსაზღვრული სვეტების მქონე ცხრილებში ინახავენ და მათ შორის კავშირებს ქმნიან. NoSQL მონაცემთა ბაზები, როგორიცაა MongoDB, უფრო მოქნილ დოკუმენტებს ინახავენ. ბიზნეს აპლიკაციების უმეტესობა, მაგალითად დაჯავშნები, CRM-ები და მაღაზიები, რელაციურ მოდელს კარგად ერგება.
მჭირდება თუ არა მონაცემთა ბაზა ჩემს აპლიკაციას?
თუ მან უნდა დაიმახსოვროს რაიმე, რასაც ადამიანები შეიყვანენ, მაგალითად რეგისტრაცია, შეკვეთები, შეტყობინებები ან პარამეტრები, და მოგვიანებით ან სხვისთვის უნდა აჩვენოს, დიახ. ჩვეულებრივი საინფორმაციო ვებსაიტი, სადაც მონაცემების შემნახავი ფორმები არ არის, ჩვეულებრივ არ სჭირდება.