Mermaid ER आरेख एडिटर
इकाई-संबंध आरेख तालिकाएँ, उनके स्तंभ और उनके आपसी जोड़ दिखाता है। यह तब ठीक है जब विषय डेटाबेस का स्कीमा हो और दिलचस्प सवाल कुंजियों तथा गुणकता के हों — एक से अनेक, वैकल्पिक, या किसी जोड़-तालिका के ज़रिए। व्यवहार और वंशानुक्रम वाले टाइप के लिए क्लास आरेख बेहतर है।
जोड़-तालिका वाला सामान्यीकृत ऑर्डर स्कीमा
ध्यान देने लायक हिस्सा ऑर्डर-पंक्ति पर लगा `}o--||` है: अनेक-से-अनेक संबंध को ईमानदारी से यही कहता है, अपने स्तंभों वाली जोड़-तालिका के ज़रिए, बजाय इसके कि दो तालिकाएँ सीधे जुड़ी होने का दिखावा किया जाए। क़ीमत को सिर्फ़ उत्पाद पर नहीं बल्कि पंक्ति पर रखना ठीक वैसा निर्णय है जिसे आरेख को दिखाना चाहिए। यह भी देखें कि यहाँ इकाइयों के नाम देवनागरी में हैं — ER आरेख में यह चलता है।
erDiagram
ग्राहक ||--o{ ऑर्डर : "देता है"
ऑर्डर ||--|{ ऑर्डर_पंक्ति : "से बना है"
उत्पाद ||--o{ ऑर्डर_पंक्ति : "में आता है"
ग्राहक ||--o{ पता : "यहाँ भेजा जाता है"
ऑर्डर ||--o| चालान : "के लिए जारी"
ग्राहक {
int आईडी PK
string ईमेल UK "छोटे अक्षरों में सहेजा जाता है"
string नाम
string जीएसटीआईएन
datetime बनाया_गया
}
ऑर्डर {
int आईडी PK
int ग्राहक_आईडी FK
string स्थिति
decimal कुल
}
ऑर्डर_पंक्ति {
int ऑर्डर_आईडी PK, FK
int उत्पाद_आईडी PK, FK
int मात्रा
decimal मूल्य "ऑर्डर के समय का मूल्य"
}
उत्पाद {
int आईडी PK
string वस्तु_कोड UK
string नाम
}
पता {
int आईडी PK
int ग्राहक_आईडी FK
string पिन_कोड
}
चालान {
int आईडी PK
string चालान_संख्या UK
decimal जीएसटी
}हल किए गए उदाहरण
1. दो इकाइयाँ और एक संबंध
हर ER संबंध कोलन के बाद एक लेबल माँगता है — फ़्लोचार्ट के किनारे से अलग, यह वैकल्पिक नहीं है। इसे वाक्य की तरह पढ़ें: ग्राहक देता है ऑर्डर।
erDiagram
ग्राहक ||--o{ ऑर्डर : "देता है"2. स्तंभ जोड़ना
हर विशेषता-पंक्ति `टाइप नाम` के रूप में होती है और दोनों हिस्से अनिवार्य हैं। `PK`, `FK` और `UK` कुंजियाँ चिह्नित करते हैं; अंत में उद्धरण चिह्नों वाला पाठ उस स्तंभ पर टिप्पणी है।
erDiagram
ग्राहक ||--o{ ऑर्डर : "देता है"
ग्राहक {
int आईडी PK
string ईमेल UK
string नाम
}
ऑर्डर {
int आईडी PK
int ग्राहक_आईडी FK
datetime दिया_गया "UTC में"
}3. वह गुणकता जो कुछ कहती है
हर इकाई के सबसे पास वाले दो चिह्न उसी इकाई की गुणकता हैं। यह उदाहरण कहता है कि किसी ऑर्डर में कम से कम एक पंक्ति होनी ही चाहिए, पर किसी ग्राहक का एक भी ऑर्डर न होना भी चलता है: एक असली बंधन, जिसे स्कीमा को लागू करना चाहिए और आरेख को दिखाना चाहिए।
erDiagram
ग्राहक ||--o{ ऑर्डर : "देता है"
ऑर्डर ||--|{ ऑर्डर_पंक्ति : "से बना है"
ऑर्डर_पंक्ति }o--|| उत्पाद : "का संदर्भ देती है"4. जोड़-तालिका के ज़रिए अनेक से अनेक
Mermaid सीधा अनेक-से-अनेक संबंध बना सकता है, पर असली स्कीमा में वह लगभग कभी नहीं होता: नीचे हमेशा एक जोड़-तालिका होती है। उसे बनाना ज़्यादा ईमानदार है और उन स्तंभों के लिए जगह देता है जो ख़ुद उस संबंध के हैं।
erDiagram
छात्र ||--o{ नामांकन : "में दाख़िला लेता है"
पाठ्यक्रम ||--o{ नामांकन : "के ज़रिए चलाया जाता है"
नामांकन {
int छात्र_आईडी PK, FK
int पाठ्यक्रम_आईडी PK, FK
datetime नामांकन_तिथि
string ग्रेड "परीक्षा तक ख़ाली"
}
छात्र {
int आईडी PK
string नाम
}
पाठ्यक्रम {
int आईडी PK
string कोड UK
}5. ख़ुद से जुड़ने वाले संबंध
कोई तालिका ख़ुद से भी जुड़ सकती है: रिपोर्टिंग की शृंखला, श्रेणियों का वृक्ष, टिप्पणियों की लड़ी। यहाँ संबंध का लेबल सामान्य से ज़्यादा मायने रखता है, क्योंकि दोनों सिरों पर वही इकाई है।
erDiagram
कर्मचारी ||--o{ कर्मचारी : "का प्रबंधन करता है"
कर्मचारी {
int आईडी PK
int प्रबंधक_आईडी FK "शीर्ष प्रबंधन के लिए ख़ाली"
string नाम
string पदनाम
}ER आरेख सिंटैक्स का सार
गुणकता संबंध के हर सिरे पर दो चिह्नों से लिखी जाती है और भीतर से बाहर की ओर पढ़ी जाती है। बायाँ जोड़ा बाईं इकाई बताता है, दायाँ जोड़ा दाईं इकाई।
| सिंटैक्स | अर्थ |
|---|---|
| erDiagram | आरेख खोलता है। बड़े-छोटे अक्षरों के प्रति संवेदनशील: `erdiagram` नहीं चलता। |
| A ||--o{ B : "लेबल" | संबंध। लेबल अनिवार्य है। |
| || | ठीक एक। |
| o| | शून्य या एक। |
| }| | एक या अधिक। |
| }o | शून्य या अधिक। |
| -- | पहचान देने वाला संबंध — ठोस रेखा। |
| .. | पहचान न देने वाला संबंध — टूटी रेखा। |
| A { ... } | इकाई A का विशेषता-खंड। |
| int आईडी PK | विशेषता: पहले टाइप, फिर नाम, फिर कुंजी-चिह्न अगर हो। |
| PK / FK / UK | प्राथमिक, विदेशी, अद्वितीय कुंजी। |
| int आईडी PK, FK | अल्पविराम से अलग किए कई कुंजी-चिह्न। |
| string ईमेल "टिप्पणी" | अंत में उद्धरण चिह्नों वाला पाठ उस स्तंभ पर टिप्पणी है। |
| A ||--o{ B : "का हिस्सा है" | जैसे ही लेबल में स्थान आए, उद्धरण चिह्न अनिवार्य हैं। उनके बिना लेबल पहले स्थान पर कट जाता है और बचा हर शब्द एक भूतिया इकाई बन जाता है। |
वे छह ग़लतियाँ जो ER आरेख को तोड़ती हैं
छहों प्रकारों में ER का व्याकरण सबसे सख़्त है: जो दूसरे आरेखों में निकल जाता है वह यहाँ खुलकर ठुकरा दिया जाता है। पर इसमें एक चुप ग़लती भी है जिसमें हिंदी में लिखते समय पड़ना ख़ास आसान है। सब कुछ Mermaid 11.12.2 पर दोबारा बनाया गया।
आपको क्या दिखता है
बन जाता है, लेबल कटा हुआ है, और आरेख में ऐसी इकाइयाँ दिखती हैं जो आपने लिखी नहीं
क्यों
संबंध के लेबल में स्थान है और उद्धरण चिह्न नहीं। हिंदी में यही सबसे ज़्यादा अड़चन डालेगा, क्योंकि हमारे संबंध-वाक्यांश लगभग हमेशा कई शब्दों के होते हैं: «का हिस्सा है», «में आता है», «यहाँ भेजा जाता है»। मापा गया: `ग्राहक ||--o{ ऑर्डर : आदेश देता है` कोई त्रुटि नहीं बताता, लेबल को «आदेश» तक छोटा कर देता है और «देता» तथा «है» नाम की दो ख़ाली इकाइयाँ बना देता है। दो तालिकाएँ चार डिब्बों के रूप में बनती हैं और कुछ भी आपको नहीं चेताता — सिवाय इसके कि viewBox 116 से 596 पिक्सल पर पहुँच जाता है।
समाधान
जिस भी लेबल में स्थान हो उसे उद्धरण चिह्नों में रखें। हिंदी में इसका मतलब व्यावहारिक रूप से हर लेबल है; हर बार तौलने के बजाय इसे नियम मान लेना आसान है।
erDiagram
ग्राहक ||--o{ ऑर्डर : आदेश देता हैerDiagram
ग्राहक ||--o{ ऑर्डर : "आदेश देता है"आपको क्या दिखता है
Parse error जो `Expecting 'COLON', 'STYLE_SEPARATOR', got 'NEWLINE'` पर ख़त्म होती है
क्यों
बिना लेबल का संबंध। फ़्लोचार्ट के किनारे से अलग, कोलन और लेबल अनिवार्य हैं: उनके बिना पंक्ति बस समय से पहले ख़त्म हो जाती है।
समाधान
कोलन और एक क्रिया-वाक्यांश जोड़ें, और अगर उसमें स्थान हो तो उद्धरण चिह्नों में।
erDiagram
ग्राहक ||--o{ ऑर्डरerDiagram
ग्राहक ||--o{ ऑर्डर : "देता है"आपको क्या दिखता है
Parse error जो `got 'UNICODE_TEXT'` पर ख़त्म होती है
क्यों
गुणकता का टोकन मान्य नहीं। सिर्फ़ `||`, `o|`, `}|` और `}o` सही हैं (और उनके दर्पण रूप); बाक़ी सब गिर जाता है। `oo` एक आम टाइपो है, जो इस मान्यता से आता है कि यह संकेतन सममित होगा।
समाधान
चारों जोड़ों में से कोई एक लें। `||--o{` — ठीक एक से शून्य या अधिक — ज़्यादातर विदेशी कुंजियों को संभाल लेता है।
erDiagram
ग्राहक ||--oo{ ऑर्डर : "देता है"erDiagram
ग्राहक ||--o{ ऑर्डर : "देता है"आपको क्या दिखता है
Parse error जो `Expecting 'ATTRIBUTE_WORD', got 'BLOCK_STOP'` पर ख़त्म होती है
क्यों
किसी विशेषता का नाम है पर टाइप नहीं। ER की विशेषताएँ `टाइप नाम` के रूप में लिखी जाती हैं, और टाइप वैकल्पिक नहीं है — यह उन लोगों को चौंकाता है जो बिना स्कीमा वाले डेटाबेस से आते हैं।
समाधान
हर विशेषता को कोई टाइप दें। असली स्कीमा में न हो तो गढ़ लें: `string`, `int`, `json`।
erDiagram
ग्राहक {
ईमेल
}erDiagram
ग्राहक {
string ईमेल
}आपको क्या दिखता है
Parse error जो `Expecting 'NON_IDENTIFYING', 'IDENTIFYING', got 'UNICODE_TEXT'` पर ख़त्म होती है
क्यों
दोनों गुणकता-चिह्नों के बीच की रेखा ग़लत है। वह ठीक दो अक्षरों की होनी चाहिए: पहचान देने वाले संबंध के लिए `--` या न देने वाले के लिए `..`। अकेला हाइफ़न `--` का संक्षिप्त रूप नहीं, बल्कि एक सिंटैक्स त्रुटि है।
समाधान
गुणकता के जोड़ों के बीच `--` या `..` लिखें।
erDiagram
ग्राहक ||-o{ ऑर्डर : "देता है"erDiagram
ग्राहक ||--o{ ऑर्डर : "देता है"आपको क्या दिखता है
गुणकता बन जाती है, पर वह उलटा बंधन बताती है
क्यों
हर इकाई के सबसे पास वाले दो चिह्न उसी इकाई के हैं, और उन्हें उलटा पढ़ लेना बहुत आसान है। `ग्राहक ||--o{ ऑर्डर` कहता है कि एक ग्राहक के शून्य या अधिक ऑर्डर होते हैं। इसे `ग्राहक }o--|| ऑर्डर` में पलटिए और आप यह दावा कर रहे हैं कि हर ग्राहक ठीक एक ऑर्डर का है, जिसका कोई मतलब नहीं — और वह ज़रा भी एतराज़ किए बिना बन जाता है।
समाधान
भीतर से बाहर की ओर पढ़ें: जो चिह्न ग्राहक को छू रहे हैं वे बताते हैं कि कितने ग्राहक हैं, कितने ऑर्डर नहीं।
erDiagram
ग्राहक }o--|| ऑर्डर : "देता है"erDiagram
ग्राहक ||--o{ ऑर्डर : "देता है"बनने के बारे में टिप्पणियाँ
Mermaid 11.12.2 पर मापा गया, वही संस्करण जो यह साइट चलाती है।
यहाँ देवनागरी इकाई के नाम के रूप में चलती है
यह जानने लायक है क्योंकि यह फ़्लोचार्ट और क्लास आरेख से अलग है। इकाई का नाम भी एक पहचान है, फिर भी देवनागरी यहाँ स्वीकार होती है — जाँचा गया, `ग्राहक ||--o{ ऑर्डर` ठीक बनता है और निकली हुई पहचानें `entity-ग्राहक` तथा `entity-ऑर्डर` होती हैं। स्तंभों के नाम भी देवनागरी में चलते हैं। सिर्फ़ स्थान मना है, इसलिए `ऑर्डर_पंक्ति` जैसे अंडरस्कोर वाले नाम रखिए और पूरे स्कीमा में वही चलन निभाइए।
हिंदी में लगभग हर लेबल को उद्धरण चिह्न चाहिए
इसे दोहराना सार्थक है, क्योंकि इस पन्ने की सबसे महँगी चुप ग़लती यही है। अंग्रेज़ी के संबंध-लेबल एक शब्द के हो सकते हैं — places, contains, references — इसलिए अंग्रेज़ी दस्तावेज़ों में उद्धरण चिह्न सजावट जैसे लगते हैं। हिंदी में इनमें से ज़्यादातर कई शब्दों के होते हैं और उद्धरण चिह्नों के बिना बिखर जाते हैं। व्यावहारिक नियम: लेबल को हमेशा उद्धरण चिह्नों में रखिए और इसके बारे में सोचना बंद कर दीजिए।
बिछावट संबंध तय करते हैं, इकाइयों की संख्या नहीं
एक के बाद एक जुड़ी इकाइयों की शृंखला ऊँचे स्तंभ की तरह बनती है: चालीस इकाइयाँ लगभग 116×7315 का viewBox देती हैं, जबकि तीन पर यह 116×470 होता है। पर वही चालीस इकाइयाँ अगर एक केंद्रीय तालिका से जुड़ी हों तो कहीं ज़्यादा चौड़ा और नीचा चित्र बनता है। यहाँ के छह प्रकारों में यही अकेला है जिसमें आपके डेटा का आकार चित्र के आकार को उसके आकारमान से ज़्यादा बदलता है, इसलिए जो स्कीमा समाता न हो वह अक्सर यह बदलकर ठीक होता है कि आप कौन-से संबंध बनाते हैं, न कि कितने।
व्याकरण छहों प्रकारों में सबसे सख़्त है
संबंध के लेबल अनिवार्य हैं, विशेषताओं के टाइप भी, और गुणकता के टोकन एक बंद समुच्चय हैं। गैंट के मुक़ाबले, जहाँ लगभग सब कुछ बन जाता है और ग़लतियाँ चुप रहती हैं, ER जल्दी और ऊँची आवाज़ में गिरता है। यह एक ख़ूबी है: अगर कोई ER आरेख बन गया, तो काफ़ी संभावना है कि वह वही आरेख है जो आपके मन में था — बिना उद्धरण चिह्नों वाले लेबल इसका साफ़ अपवाद हैं।
लेबल HTML हैं, इसलिए PNG निर्यात दोबारा बनाता है
इकाइयों की विशेषता-तालिकाएँ SVG के भीतर `<foreignObject>` में बनती हैं, इसलिए ब्राउज़र उन्हें सीधे कैनवस पर नहीं उतार पाते। इस साइट का PNG निर्यात पहले चुपचाप SVG फ़ाइल लौटाता था; अब वह आरेख को पहले सादे SVG पाठ-लेबल के साथ दोबारा बनाता है और सही, पूरे आकार का PNG देता है, जिसकी टाइपसेटिंग बस ज़रा-सी अलग होती है।
कब कोई दूसरा आरेख बेहतर है
अगर आपको वंशानुक्रम, इंटरफ़ेस या विधियाँ चाहिए तो यह ग़लत आरेख है: ER में इनमें से कोई अवधारणा है ही नहीं। क्लास आरेख लीजिए और यह मान लीजिए कि वह आपके कोड का मॉडल बनाता है, आपकी तालिकाओं का नहीं।
अगर स्कीमा बड़ा है, तो पूरे का ER आरेख दीवार का ऐसा पोस्टर बन जाता है जिसे कोई नहीं पढ़ता। उन पाँच तालिकाओं को बनाइए जो उस बात से जुड़ी हैं जो आप उस समय समझा रहे हैं, और बाक़ी को चौखटे से बाहर रहने दीजिए; आरेख एक तर्क है, सूची नहीं।
और अगर असली सवाल यह है कि डेटा तंत्रों के बीच कैसे बहता है, न कि वह कैसे सहेजा जाता है, तो उसका जवाब हर तंत्र के लिए एक सबग्राफ़ वाला फ़्लोचार्ट देता है, ER आरेख नहीं।
अन्य आरेख प्रकार
लिखा Dominik Malsch · अंतिम अद्यतन: