პსევდონიმები

ვცვლით სვეტების სახელებს

ასევე უნდა გავერკვეთ სვეტების სახელებში. ხომ გვიმეორდება სახელები name და id, თუმცა ისინი სხვადასხვა მონაცემებს შეიცავენ. ასევე არსებობს პირველი სვეტი id და სვეტი employee_id, რომლებიც ერთსა და იმავე მონაცემებს მოიცავენ.

დავწეროთ მოთხოვნა, სადაც მხოლოდ საჭირო სვეტები იქნება და გადავარქვათ ერთნაირ სახელებს:

SELECT task.id AS task_id, task.name AS task_desc, task.deadline AS deadline, employee.id AS employee_id, employee.name AS emp_name, employee.occupation AS emp_occupation FROM employee, task WHERE employee.id = task.employee_id 

და ასეთი მოთხოვნის შედეგი:

შესანიშნავია, გაუგებარი სვეტების სახელების პრობლემა წარმატებით გადაიჭრა. მოთხოვნა ცოტა დიდი გამოდგა, მაგრამ შედეგში ყველაფერი გასაგებია. ზედმეტი სვეტები არ გვაქვს.

ცხრილის ალიასები

ზოგჯერ ცხრილების სახელები ზედმეტად გრძელია და ბევრ სივრცეს იკავებს მოთხოვნაში. ამიტომ, SQL სემქმნელებმა მოუწოდეს ალიასების გამოყენება, როგორც სვეტების სახელებთან დაკავშირებით.

ცხრილის ალიასის ზოგადი ფორმატია ასეთი:

FROM ცხრილი1 ფსევდონიმი1, ცხრილი2 ფსევდონიმი2 

მოდით, გადავიწეროთ წინა მოთხოვნა მოკლე ფსევდონიმებით:

SELECT t.id AS task_id, t.name AS task_desc, t.deadline AS deadline, e.id AS employee_id, e.name AS emp_name, e.occupation AS emp_occupation  FROM employee e, task t  WHERE e.id = t.employee_id 

მომხმარებლიურობა ოდნავ შემცირდა, მაგრამ ეს იმიტომ, რომ ცხრილების სახელები თავიდანვე მარტივი და გასაგები იყო. თუმცა შეიძლება ისე:

SELECT task.id AS task_id, task.name AS task_desc, task.deadline AS deadline, employee.id AS employee_id, employee.name AS emp_name, employee.occupation AS emp_occupation  FROM  Microsoft_it_department_employee employee, Year2022_priority_task task WHERE employee.id = task.employee_id 

ამ შემთხვევაში ალიასები ნამდვილად სარგებლიანია, ხომ? ;)

პირველადი გასაღები

კიდევ ერთი მნიშვნელოვანი ინფორმაცია ცხრილებთან დაკავშირებით. გახსოვს, ცხრილში task გვქონდა სვეტი employee_id? მისი მეშვეობით ვსვამდით თანამშრომლის ID-ს ცხრილიდან employee.

თუ გვსურს ცხრილების ერთმანეთზე მიბმა, ცხრილმა, რომელზეც მითითებულია, უნდა ჰქონდეს ID სვეტი, რომელიც ცნობილი როგორც პირველადი გასაღები — PRIMARY KEY.

ხშირად ეს არის სპეციალურად დამატებული სვეტი, რომლის მნიშვნელობების ტიპია — int. ცხრილში ჩანაწერების დამატებისას SQL ავტომატურად ადგენს ამ სვეტის მნიშვნელობებს.

ამ გასაღებებზე მერე ბევრი რამე ეკრაშება:

• ცხრილების ერთმანეთთან მიბმა;
• სწრაფი ძიება და ფილტრაცია id-ზე;
• მონაცემთა მთლიანობა ბაზაში (არარსებული id-ზე არ არის მითითება);
• არასავალდებულო მონაცემების წაშლა;
• და ბევრი სხვა.

სხვათა შორის, бывают სიტუაციები, როდესაც ცხრილს აქვს ე.წ. ნატურალური გასაღები. ეს არის, როდესაც სვეტი, რომლის შემცველობა უნიკალურია. მაგალითად, გადავწყვიტეთ თანამშრომლების ცხრილში დავამატოთ:

• კომპანიაში მოსვლის რიგის ნომერი;
• საგადასახადო ნომერი;
• პასპორტის ნომერი და სერია.

ზოგჯერ მონაცემთა ბაზების დიზაინერები იყენებენ ნატურალურ გასაღებს, როგორც პირველადი გასაღები, მაგრამ ხშირად ისინი ცალკე იყენებენ. ჩანაწერები კი შეიძლება წაშლილი, შეცვლილი და ა.შ.

თქვენ ალბათ წაგიკითხავთ ისტორიები ინტერნეტში, როდესაც ადამიანზე ვალდებულებით მოედება მისი სრული წარწერა? ეს სწორედ უნიკალური გასაღების ცნებაზეა დაკავშირებული. ბანკებს და ბროკერებს ძალიან მოსახერხებელი აქვთ პირის ძიება სახელით და დაბადების თარიღით. და 99% შემთხვევაში ეს საკმარისია პიროვნების განსაცნობად.

თუმცა დანარჩენი <1% — ეს არის სრული თანამოსახლეები, იგივე დაბადების თარიღით. ჩვენს ცხოვრებაში ეს ალბათ არ არის, მაგრამ ქვეყნის მასშტაბით — არის. ასე რომ, თუ პროგრამულ უზრუნველყოფას წერენ ან მონაცემთა ბაზას პროექტზე, ეს სასარგებლოა იცოდეს, რომ ესეც ასე შეიძლება იყოს.