อ่านข้อมูลของแอปตัวเองให้ออก แล้วหมอกจะกลายเป็นแผนที่

คุณนั่งมองแอปที่ตัวเองสร้างขึ้นมากับมือ แล้วรู้สึกว่ามันใหญ่เกินกว่าจะเข้าใจได้ทั้งหมด มีหน้าจอนู้นหน้าจอนี้ มีปุ่ม มีข้อมูลโผล่มาจากไหนไม่รู้ มีตัวแปรเต็มไปหมด อันนี้ต่อกับอันไหน แก้ตรงนี้แล้วจะกระทบตรงไหน คุณตอบไม่ได้ ทั้งหมดมันเหมือนกองชิ้นส่วนยุ่บยั่บที่ขยับไปขยับมาตลอดเวลา จับต้นชนปลายไม่ถูก

ความรู้สึกนี้มีชื่อในใจคุณว่า "มันซับซ้อนเกินไป" คุณเลยไม่กล้าแตะ กลัวว่าพอดึงตรงนี้ อีกสิบที่จะพังตามโดยที่คุณไม่รู้ว่าทำไม แอปทั้งแอปกลายเป็นหมอกหนา ๆ ที่คุณมองทะลุไม่เห็น

Part A เล่าไปแล้วว่าแอปคุณมี "ที่เก็บข้อมูล" หรือ database คือส่วนที่จำข้อมูลไว้แบบถาวร ไม่ได้อยู่บนหน้าจอ แต่นอนอยู่เบื้องหลัง บทนั้นบอกว่ามันมีอยู่ และทำหน้าที่อะไร แต่ database ไม่ได้เก็บข้อมูลกองรวมกันมั่ว ๆ มันเก็บเป็น "รูปร่าง" ที่มีระเบียบ และรูปร่างนั้นเองคือสิ่งที่ทำให้แอปรู้สึกซับซ้อน บทนี้คือบทที่พาคุณอ่านรูปร่างนั้นให้ออก

ข่าวดีคือ สิ่งที่คุณรู้สึกว่าซับซ้อนนั้น ส่วนใหญ่ไม่ได้ซับซ้อนอย่างที่คิด มันแค่ดูเยอะ เพราะคุณยังไม่เห็น "โครงร่าง" ของข้อมูลที่ database เก็บไว้ และพอคุณเห็นโครงร่างนี้ หมอกจะจางลงทันที สิ่งที่เคยเป็นกองชิ้นส่วนกระจัดกระจาย จะกลายเป็นแผนที่ที่คุณถือไว้ในหัวได้ทั้งแอป บทนี้จะพาคุณไปดูว่าโครงร่างนั้นคืออะไร และทำไมพอเห็นมันแล้ว แอปทั้งแอปถึงเข้าใจง่ายขึ้นมาก

ความซับซ้อนที่คุณกลัว ส่วนใหญ่คือ "รูปร่างของข้อมูล"

ลองนึกย้อนไปตอนที่คุณรู้สึกว่าแอปมันซับซ้อน คุณกำลังกลัวอะไรกันแน่

ส่วนใหญ่ไม่ใช่กลัวโค้ดทีละบรรทัด เพราะคุณก็ไม่ได้อ่านโค้ดอยู่แล้ว สิ่งที่ทำให้รู้สึกซับซ้อนจริง ๆ คือคุณไม่รู้ว่าแอปมัน "เก็บอะไรไว้บ้าง" และ "ของแต่ละอย่างเกี่ยวกันยังไง" หน้า dashboard ดึงข้อมูลมาจากไหน ทำไมพอลบของชิ้นนี้ ของอีกชิ้นถึงหายตามไปด้วย ทำไมผู้ใช้คนนี้เห็นของชุดนี้ แต่อีกคนเห็นอีกชุด

ความสับสนพวกนี้แทบทั้งหมดมีต้นตอเดียวกัน คือคุณยังไม่เห็นภาพว่าข้อมูลในแอปของคุณ "มีหน้าตาเป็นรูปร่างยังไง" มีของกี่ชนิด แต่ละชนิดเก็บรายละเอียดอะไรไว้บ้าง และของชนิดหนึ่งโยงกับอีกชนิดยังไง

นี่คือสิ่งที่คนในวงการเรียกว่า data model หรือบางทีเรียกว่า schema แปลเป็นภาษาคนคือ "โครงร่างของข้อมูล" มันคือแบบแปลนที่บอกว่า database ของแอปคุณเก็บข้อมูลอะไรไว้ และข้อมูลแต่ละก้อนเชื่อมโยงกันยังไง database ที่ Part A พูดถึงเก็บข้อมูลเป็นรูปร่างแบบนี้เสมอ และบทนี้คือบทที่จะพาคุณอ่านรูปร่างนั้นให้ออกจนเห็นภาพจริง ๆ

💡 ใจความสำคัญ: สิ่งที่คุณรู้สึกว่าเป็น "ความซับซ้อนของแอป" ส่วนใหญ่จริง ๆ คือ "ความซับซ้อนของรูปร่างข้อมูล" พอคุณเข้าใจว่าแอปเก็บอะไรไว้บ้าง และของแต่ละชิ้นโยงกันยังไง หมอกที่เคยปกคลุมทั้งแอปจะจางลงเกือบหมด เพราะพฤติกรรมของแอปส่วนใหญ่ ก็แค่ทำตามรูปร่างของข้อมูลนั้นเอง

โครงร่างข้อมูลมีแค่สี่ส่วน เท่านั้นจริง ๆ

ข่าวดีกว่านั้นคือ โครงร่างข้อมูลของแอปแทบทุกตัว ประกอบขึ้นจากของแค่สี่อย่าง พอคุณรู้สี่อย่างนี้ คุณจะวาดโครงร่างของแอปตัวเองออกมาได้ ลองไปทีละชิ้น

หนึ่ง ชนิดของของ ในวงการเรียกว่า table แปลตรงตัวว่า "ตาราง" คือการแบ่งว่าแอปคุณมีของกี่ "ชนิด" เช่น แอปคุณอาจมีชนิด "ผู้ใช้" ชนิด "บทความที่บันทึกไว้" ชนิด "คำสั่งซื้อ" แต่ละชนิดคือหนึ่ง table ลองคิดว่ามันคือชื่อหัวข้อใหญ่ ๆ ของข้อมูล

สอง ตัวอย่างแต่ละชิ้นของชนิดนั้น ในวงการเรียกว่า row แปลตรงตัวว่า "แถว" ถ้า table คือชนิด "ผู้ใช้" แล้ว row ก็คือผู้ใช้ทีละคน คุณสมชายหนึ่ง row คุณสมหญิงอีกหนึ่ง row table "ผู้ใช้" ที่มีคนสมัครหมื่นคน ก็คือตารางที่มีหมื่นแถว แถวละคน

สาม รายละเอียดของแต่ละชิ้น ในวงการเรียกว่า column แปลตรงตัวว่า "ช่อง" หรือ "คอลัมน์" คือช่องข้อมูลย่อยที่ทุก row ในชนิดนั้นมีเหมือนกัน เช่น ผู้ใช้ทุกคนมีช่อง "อีเมล" ช่อง "ชื่อ" ช่อง "วันที่สมัคร" column คือการกำหนดว่าของชนิดนี้ เราจดอะไรไว้บ้างเกี่ยวกับมัน

สี่ ความเชื่อมโยงระหว่างชนิด ในวงการเรียกว่า relationship แปลตรงตัวว่า "ความสัมพันธ์" คือเส้นที่ลากเชื่อมว่าของชนิดหนึ่งเกี่ยวกับของอีกชนิดยังไง เช่น "บทความที่บันทึกไว้" หนึ่งชิ้น เป็นของ "ผู้ใช้" คนใดคนหนึ่ง ความเชื่อมโยงแบบนี้เรียกว่า บทความที่บันทึกไว้ เป็นของ ผู้ใช้ พอคุณลากเส้นพวกนี้ครบ คุณจะเห็นเลยว่าทำไมลบผู้ใช้คนหนึ่ง บทความที่เขาบันทึกไว้ถึงควรหายตามไปด้วย เพราะมันผูกอยู่กับเขา

สี่อย่างนี้คือทั้งหมด ตาราง (ชนิด) แถว (ทีละชิ้น) ช่อง (รายละเอียด) และเส้น (ความเชื่อมโยง) แอปที่ดูยุ่บยั่บที่สุด พอแกะออกมาเป็นโครงร่างข้อมูล ก็คือกล่องไม่กี่กล่องกับเส้นไม่กี่เส้น เท่านั้นเอง

ทำไมพอเห็นรูปร่างข้อมูล แอปทั้งแอปถึงกระจ่าง

ตรงนี้คือหัวใจ เหตุผลที่โครงร่างข้อมูลทำให้หมอกจาง ไม่ใช่แค่เพราะมันเป็นระเบียบ แต่เพราะ ฟีเจอร์ส่วนใหญ่ในแอป จริง ๆ แล้วคือการ "ทำอะไรสักอย่างกับรูปร่างข้อมูลนี้" เท่านั้นเอง

ลองดูว่าฟีเจอร์ที่คุณเห็นในแอปทั่วไป แกะออกมาเป็นภาษาข้อมูลแล้วเหลืออะไร

• หน้าที่โชว์รายการ คือ "หยิบ row ทั้งหมดในชนิดนี้มาเรียงให้ดู"
• ปุ่มเพิ่มของ คือ "สร้าง row ใหม่ในชนิดนี้"
• ปุ่มลบ คือ "เอา row นี้ออกไป"
• ปุ่มแก้ไข คือ "เปลี่ยนค่าในช่องของ row นี้"
• หน้าที่โชว์เฉพาะของฉัน คือ "หยิบเฉพาะ row ที่ช่อง เป็นของผู้ใช้คนไหน ตรงกับฉัน"

เห็นไหมว่าพอแกะออกมาแล้ว ฟีเจอร์ที่ดูเป็นคนละเรื่องกันบนหน้าจอ จริง ๆ คือการกระทำซ้ำ ๆ ไม่กี่แบบ บนรูปร่างข้อมูลก้อนเดิม นี่คือเหตุผลที่พอคุณวาดโครงร่างข้อมูลของแอปออกมาได้ คุณจะเริ่ม "เดาออก" ว่าแต่ละฟีเจอร์ทำงานยังไง โดยไม่ต้องอ่านโค้ดเลย เพราะพฤติกรรมของแอปส่วนใหญ่แค่เดินตามรูปร่างของข้อมูล

และนี่คือจุดที่ต้องแก้ความเข้าใจผิดสองข้อ

หลายคนคิดว่า ฐานข้อมูลคือหัวใจทางเทคนิคที่น่ากลัวที่สุดของแอป เป็นส่วนลึกลับที่คนไม่ใช่โปรแกรมเมอร์ไม่มีวันเข้าใจ จริง ๆ มันกลับกันเลย โครงร่างข้อมูลคือส่วนที่ เรียนรู้ง่ายที่สุด ของทั้งแอป มันคือแผนที่ที่อ่านออกเป็นภาษาคนได้ตรง ๆ ตารางชื่ออะไร เก็บอะไร โยงกับอะไร เป็นสิ่งที่คุณนั่งวาดบนกระดาษได้ ในขณะที่โค้ดจริง ๆ ที่ทำงานเบื้องหลัง ยุ่งยากกว่ามาก ส่วนที่คุณกลัวที่สุด จริง ๆ คือส่วนที่ช่วยคุณได้มากที่สุด

อีกข้อ หลายคนคิดว่า ตัวแปรในแอปมันเยอะแยะไม่รู้จบ เต็มไปหมดจนตามไม่ไหว จริง ๆ ตัวแปรส่วนใหญ่ไม่ได้ลอยมาจากไหน มันสาวกลับไปที่รูปร่างข้อมูลได้แทบทั้งหมด ค่าที่โผล่บนหน้าจอ ก็คือ column สักช่องของ row สักแถว สิ่งที่ดูเหมือนตัวแปรนับไม่ถ้วน จริง ๆ คือข้อมูลชุดเดิมที่ถูกหยิบไปแสดงในที่ต่าง ๆ พอคุณรู้รูปร่างข้อมูล คุณก็รู้ว่าค่าพวกนั้นมาจากไหน

เปรียบเหมือนตู้เอกสารของบริษัท

ถ้าจะให้เห็นภาพชัด ลองนึกถึงตู้เก็บเอกสารของบริษัทที่จัดระเบียบดี ๆ

ตู้เอกสารหนึ่งใบ แบ่งเป็นลิ้นชักหลายลิ้นชัก ลิ้นชักหนึ่งสำหรับเอกสาร "พนักงาน" อีกลิ้นชักสำหรับ "ใบสั่งซื้อ" อีกลิ้นชักสำหรับ "ลูกค้า" หนึ่งลิ้นชักคือของหนึ่งชนิด นี่คือ table

ในลิ้นชัก "พนักงาน" มีแฟ้มเรียงกันเป็นปึก แฟ้มละคน คุณสมชายหนึ่งแฟ้ม คุณสมหญิงอีกหนึ่งแฟ้ม แต่ละแฟ้มคือ row

เปิดแฟ้มเข้าไป ข้างในเป็นแบบฟอร์มมาตรฐาน มีช่องให้กรอกเหมือนกันทุกแฟ้ม ช่องชื่อ ช่องอีเมล ช่องวันเริ่มงาน ทุกแฟ้มในลิ้นชักเดียวกันใช้ฟอร์มหน้าตาเดียวกัน ช่องพวกนี้คือ column

และในแฟ้ม "ใบสั่งซื้อ" จะมีช่องเขียนว่า "ลูกค้าเลขที่เท่าไร" ซึ่งชี้ไปที่แฟ้มในลิ้นชัก "ลูกค้า" อีกที นี่คือการอ้างอิงข้ามลิ้นชัก คือ relationship เส้นที่โยงของชนิดหนึ่งไปอีกชนิด

พอคิดภาพแบบนี้ โครงร่างข้อมูลก็ไม่ใช่เรื่องน่ากลัวเลย มันคือตู้เอกสารที่จัดดี ลิ้นชักหนึ่งต่อหนึ่งชนิด ทุกแฟ้มใช้ฟอร์มมาตรฐาน และมีการอ้างอิงข้ามลิ้นชักไว้

แต่การเปรียบเทียบนี้ใช้ได้แค่จุดหนึ่ง จุดที่มันต่างคือ ตู้เอกสารกระดาษเป็นของตายนิ่ง ๆ ใครเปิดลิ้นชักได้ก็หยิบดูได้ทุกแฟ้ม แต่ข้อมูลในแอปมี "กฎที่ทำงานเป็น ๆ" ฝังอยู่ด้วย เช่นกฎที่ว่า ผู้ใช้แต่ละคนเห็นได้แค่ row ของตัวเอง กฎพวกนี้ถูกบังคับให้ทำงานอัตโนมัติทุกครั้งที่มีคนมาขอดูข้อมูล ราวกับลิ้นชักรู้เองว่าใครมายืนอยู่หน้าตู้ แล้วยอมให้หยิบเฉพาะแฟ้มของคนนั้น ตู้กระดาษทำแบบนี้ไม่ได้ กฎที่มีชีวิตพวกนี้สำคัญมากเรื่องความปลอดภัย เดี๋ยวบทนี้จะแนะนำให้รู้จักมันเต็ม ๆ ในตัวอย่างจริงข้างล่าง บทนี้แค่อยากให้คุณรู้ก่อนว่ามันมีอยู่

ตัวอย่างจริง โครงร่างข้อมูลของเว็บนี้

ทีนี้มาดูของจริง เว็บ AI ภาษาคน ที่คุณกำลังอ่านอยู่นี้ คนสร้างไม่ใช่โปรแกรมเมอร์ เขาเป็นผู้บริหารสายธุรกิจ สร้างเว็บนี้ขึ้นมาด้วยการสั่ง AI ล้วน ๆ และมันก็ขึ้นใช้งานจริงอยู่ตอนนี้ ส่วนที่เก็บข้อมูลผู้ใช้ของเว็บนี้ ตั้งอยู่บนบริการเช่าชื่อ Supabase ซึ่งทำหน้าที่เป็นทั้งระบบล็อกอินและฐานข้อมูลให้

โครงร่างข้อมูลของเว็บนี้ ถ้าวาดออกมาบนกระดาษ มีของแค่สามชนิด สาม table

• ผู้ใช้ (Users) หนึ่ง row ต่อหนึ่งคนที่สมัคร มีช่องอีเมล ช่องวิธีล็อกอิน (อีเมลกับรหัส หรือล็อกอินด้วย Google)
• บทความที่บันทึกไว้ (Bookmarks) หนึ่ง row ต่อหนึ่งบทความที่ผู้ใช้กดบันทึก แต่ละ row มีช่องที่บอกว่า เป็นของผู้ใช้คนไหน
• บทที่เรียนจบ (Completions) หนึ่ง row ต่อหนึ่งบทที่ผู้ใช้อ่านจบ แต่ละ row ก็มีช่องที่บอกว่า เป็นของผู้ใช้คนไหน

เส้นความเชื่อมโยงในนี้ก็ตรงไปตรงมา บทความที่บันทึกไว้หนึ่งชิ้น เป็นของ ผู้ใช้คนหนึ่ง บทที่เรียนจบหนึ่งชิ้น ก็เป็นของ ผู้ใช้คนหนึ่ง ผู้ใช้คนเดียวมีบทความที่บันทึกได้หลายชิ้น และมีบทที่เรียนจบได้หลายบท แต่ของแต่ละชิ้นผูกกับเจ้าของแค่คนเดียว

ทีนี้ดูหน้า dashboard ที่ผู้ใช้เห็นหลังล็อกอิน หน้าที่ /learn มันโชว์บทความที่คุณบันทึกไว้ กับบทที่คุณเรียนจบ ดูเป็นฟีเจอร์ที่ต้องเขียนอะไรซับซ้อนใช่ไหม จริง ๆ พอแกะออกมาเป็นภาษาข้อมูล มันคือประโยคเดียวสั้น ๆ "หยิบ row ใน Bookmarks และ Completions เฉพาะที่ เป็นของ ผู้ใช้คนนี้ มาแสดง" เท่านั้นเอง ตัวฟีเจอร์ ก็คือรูปร่างของข้อมูลนั่นแหละ ไม่ได้มีเวทมนตร์อะไรซ่อนอยู่ใต้นั้น

แล้วกฎที่ว่าคุณเห็นได้แค่ของคุณ ไม่เห็นบทที่คนอื่นบันทึกล่ะ มาจากไหน มันคือกฎที่มีชีวิตที่พูดถึงตอนเปรียบกับตู้เอกสาร และนี่คือนิยามที่บทนี้อยากให้คุณติดตัวไป ในวงการเรียกกฎนี้ว่า row-level security หรือเรียกย่อ ๆ ว่า RLS แปลเป็นภาษาคนคือ "กฎระดับแถว" คือกฎที่ฝังอยู่ที่ตัว database เอง บังคับอัตโนมัติทุกครั้งว่า ใครก็ตามที่ขอดูข้อมูล ให้ส่งกลับไปแค่ row ที่เป็นของคนนั้น ไม่ใช่ทั้งตาราง พูดง่าย ๆ คือ RLS คือกฎที่ทำให้ผู้ใช้แต่ละคนเห็นได้แค่แถวของตัวเอง คนสร้างเว็บนี้ไม่ได้สร้างระบบล็อกอินและกฎพวกนี้ขึ้นเองจากศูนย์ เขายืนอยู่บน Supabase ที่มีของพวกนี้ให้

กฎ RLS นี้คือด่านความปลอดภัยสำคัญ และเพราะมันสำคัญขนาดนี้ ถ้าตั้งพลาดคนหนึ่งจะเห็นข้อมูลของอีกคนได้ทันที แผนที่จุดอันตราย เลยหยิบ RLS ไปลงรายละเอียดในฐานะ "เขตอันตราย" ที่ต้องระวังเป็นพิเศษเวลาแก้ ส่วนบทนี้แค่ขอให้คุณรู้จักมันให้ชัดก่อนว่า RLS คืออะไร และเห็นว่ากฎความปลอดภัยทั้งหมดนี้ ก็เป็นส่วนหนึ่งของรูปร่างข้อมูลเหมือนกัน

จุดที่อยากให้คุณเห็นคือ เว็บที่ใช้งานจริง มีคนล็อกอิน มี dashboard ส่วนตัว มีระบบความปลอดภัย ฟังดูซับซ้อนมาก แต่พอวาดโครงร่างข้อมูลออกมา มันคือกล่องสามกล่อง กับเส้นโยงไม่กี่เส้น กับกฎหนึ่งข้อว่าใครเห็นของใคร นั่นคือทั้งหมด

ลองทำดู วาดโครงร่างข้อมูลของแอปคุณเอง

ปิดโค้ดไปก่อน หยิบกระดาษมาหนึ่งแผ่น แล้วลองตอบสามคำถามนี้เกี่ยวกับแอปที่คุณสร้าง

หนึ่ง แอปของคุณเก็บของกี่ "ชนิด" ลองไล่ออกมาเป็นคำนาม ผู้ใช้ คำสั่งซื้อ สินค้า ข้อความ อะไรก็ตามที่แอปคุณต้องจำไว้ วาดกล่องหนึ่งกล่องต่อหนึ่งชนิด นี่คือ table ของคุณ

สอง ในแต่ละกล่อง คุณจดรายละเอียดอะไรไว้บ้างเกี่ยวกับของชนิดนั้น เขียนเป็นบรรทัดย่อยในกล่อง เช่นในกล่องผู้ใช้ อาจมี อีเมล ชื่อ วันสมัคร นี่คือ column

สาม ลากเส้นระหว่างกล่อง ของชนิดนี้ เป็นของ หรือ เกี่ยวกับ ของชนิดไหนอีก เขียนคำกำกับบนเส้นว่ามันเชื่อมกันยังไง นี่คือ relationship

ถ้าคุณวาดสามอย่างนี้ออกมาได้ ต่อให้หยาบ ๆ ก็ตาม แปลว่าคุณ "อ่านแอปตัวเองออก" แล้ว และคุณยังเอาแผ่นนี้ไปคุยกับ AI ได้ตรง ๆ ด้วย พอคุณบอกมันว่า "แอปฉันมีสาม table คือ A B C โยงกันแบบนี้" AI จะเข้าใจสิ่งที่คุณกำลังจะแก้ได้เร็วและแม่นขึ้นมาก เพราะคุณชี้ให้มันเห็นรูปร่างข้อมูลแล้ว ไม่ใช่ปล่อยให้มันเดาเอง

สรุป หมอกที่กลายเป็นแผนที่

กลับไปที่ความรู้สึกตอนต้น แอปที่ดูเหมือนกองชิ้นส่วนยุ่บยั่บที่ใหญ่เกินกว่าจะถือไว้ในหัวได้ ความจริงคือ ความซับซ้อนที่คุณกลัวส่วนใหญ่ ไม่ได้อยู่ในโค้ด มันอยู่ที่ว่าคุณยังไม่เห็นรูปร่างของข้อมูล

พอคุณรู้ว่าโครงร่างข้อมูลมีแค่สี่ส่วน ชนิดของของ (table) ทีละชิ้น (row) ช่องรายละเอียด (column) และเส้นเชื่อมโยง (relationship) คุณก็วาดแอปตัวเองออกมาเป็นแผนที่ได้ และพอคุณเห็นแผนที่นั้น ฟีเจอร์ส่วนใหญ่ที่เคยดูลึกลับ ก็กลายเป็นแค่ "ทำอะไรสักอย่างกับรูปร่างข้อมูลนี้" หยิบมาแสดง สร้างใหม่ ลบทิ้ง แก้ค่า หรือกรองเอาเฉพาะของฉัน

เว็บที่คุณกำลังอ่านนี้พิสูจน์ให้เห็นแล้ว เว็บที่ใช้งานจริง มีล็อกอิน มี dashboard ส่วนตัว มีความปลอดภัย พอแกะออกมาคือกล่องสามกล่อง กับเส้นไม่กี่เส้น dashboard ทั้งหน้า จริง ๆ คือประโยคเดียว "แสดงของที่เป็นของผู้ใช้คนนี้"

หมอกไม่ได้หายเพราะคุณเก่งขึ้นกะทันหัน มันหายเพราะคุณมองเห็นโครงสร้างที่อยู่ใต้มันมาตลอด ครั้งหน้าที่แอปคุณรู้สึกซับซ้อนเกินรับไหว อย่าเพิ่งถอย ให้ถามตัวเองก่อนว่า ฉันวาดรูปร่างข้อมูลของมันออกมาได้หรือยัง เพราะพอวาดได้ หมอกก็จะกลายเป็นแผนที่ที่คุณถือไว้ได้ทั้งแอป

---

อ่านต่อ: คลิกครั้งเดียวไม่ใช่การรู้ว่ามันใช้ได้

แหล่งอ้างอิง

• https://supabase.com/docs/guides/database/tables
• https://supabase.com/docs/guides/auth/row-level-security