text:
Medical sign
From Wikipedia, the free encyclopedia
Jump to: navigation, search
A medical sign is an objective[1] indication of some medical fact or characteristic that may be detected by a patient or anyone, especially a physician, before or during a physical examination of a patient. For example, whereas a tingling paresthesia is a symptom (only the person experiencing it can directly observe their own tingling feeling), erythema is a sign (anyone can confirm that the skin is redder than usual). Symptoms and signs are often nonspecific, but often combinations of them are at least suggestive of certain diagnoses, helping to narrow down what may be wrong. In other cases they are specific even to the point of being pathognomonic.
Semiotics
General concepts
Sign
(relation
relational complex)
Code
Confabulation
Connotation / Denotation
Encoding / Decoding
Lexical
Modality
Representation
Salience
Semiosis
Semiosphere
Semiotic theory of Peirce
Umwelt
Value
Fields
Biosemiotics
Cognitive semiotics
Computational semiotics
Literary semiotics
Semiotics of culture
Methods
Commutation test
Paradigmatic analysis
Syntagmatic analysis
Semioticians
Mikhail Bakhtin
Roland Barthes
Marcel Danesi
John Deely
Umberto Eco
Gottlob Frege
Algirdas Julien Greimas
Félix Guattari
Louis Hjelmslev
Vyacheslav Ivanov
Roman Jakobson
Roberta Kevelson
Kalevi Kull
Juri Lotman
Charles W. Morris
Charles S. Peirce
Augusto Ponzio
Ferdinand de Saussure
Thomas Sebeok
Michael Silverstein
Eero Tarasti
Vladimir Toporov
Jakob von Uexküll
Related topics
Copenhagen–Tartu school
Tartu–Moscow Semiotic School
Post-structuralism
Structuralism
Postmodernity
v
t
e
Some signs may have no meaning to the patient, and may even go unnoticed, but may be meaningful and significant to the healthcare provider in assisting diagnosis.
Examples of signs include elevated blood pressure, a clubbing of the ends of fingers (which may be a sign of lung disease, or many other things), a staggering gait (human) and arcus senilis of the eyes.
The term sign is not to be confused with the term indication, which in medicine denotes a valid reason for using some treatment.
Contents
[hide]
1 Semiotics
2 Versus symptoms
3 Types
4 Technological development creating signs detectable only by physicians
4.1 Advances in the 19th century
4.2 Alteration of the relationship between physician and patient
5 As tests
6 Examples of signs
7 See also
8 References
9 External links
Semiotics[edit]
The art of interpreting clinical signs was originally called semiotics (a term now used for the study of sign communication in general) in English. This term, then written semeiotics (derived from the Greek adjective σημειωτικός: semeiotikos, "to do with signs"), was first used in English in 1670 by Henry Stubbes (1631–1676), to denote the branch of medical science relating to the interpretation of signs:
...nor is there any thing to be relied upon in Physick, but an exact knowledge of medicinal phisiology (founded on observation, not principles), semeiotics, method of curing, and tried (not excogitated, not commanding) medicines....[2]
Versus symptoms[edit]
Signs are different from symptoms, the subjective experiences, such as fatigue, that patients might report to their examining physician.
For convenience, signs are commonly distinguished from symptoms as follows: Both are something abnormal, relevant to a potential medical condition, but a symptom is experienced and reported by the patient, while a sign is discovered by the physician during examination or by a clinical scientist by means of an in vivo examination of the patient.[3]:75
A slightly different definition views signs as any indication of a medical condition that can be objectively observed (i.e., by someone other than the patient), whereas a symptom is merely any manifestation of a condition that is apparent to the patient (i.e., something consciously affecting the patient). From this definition, it can be said that an asymptomatic patient is uninhibited by disease. However, a doctor may discover the sign hypertension in an asymptomatic patient, who does not experience "dis-ease", and the sign indicates a disease state that poses a hazard to the patient. With this set of definitions, there is some overlap – certain things may qualify as both a sign and a symptom (e.g., a bloody nose).
Lester S. King, author of Medical Thinking, argues that an "essential feature" of a sign is that there is both a sign [or "signifier"] and a "thing signified". And, because "the essence of a sign is to convey information", it can only be a sign, properly speaking, if it has meaning. Therefore, "a sign ceases to be a sign when you cannot read it".[3]:73–74 A person, who has and exercises the knowledge required to understand the significance or indication or meaning of the sign, is necessary for something to be a complete sign. A physical phenomenon that is not actually interpreted as a sign pointing to something else is, in medicine, merely a symptom. Thus, King rejects "these present-day views [distinguishing signs from symptoms based on patient-subjective versus clinician-objective], however widely accepted, as quite faulty, at variance not only with ordinary usage but with the entire history of medicine."[3]:77
"[A] symptom is a phenomenon, caused by an illness and observable directly in experience. We may speak of it as a manifestation of illness. When the observer reflects on that phenomenon and uses it as a base for further inferences, then that symptom is transformed into a sign. As a sign it points beyond itself — perhaps to the present illness, or to the past or to the future. That to which a sign points is part of its meaning, which may be rich and complex, or scanty, or any gradation in between. In medicine, then, a sign is thus a phenomenon from which we may get a message, a message that tells us something about the patient or the disease. A phenomenon or observation that does not convey a message is not a sign. The distinction between signs and symptom rests on the meaning, and this is not perceived but inferred."[3]:81
Types[edit]
Medical signs may be classified by the type of inference that may be made from their presence, for example:
Prognostic signs (from progignṓskein, προγιγνώσκειν, "to know beforehand"): signs that indicate the outcome of the current bodily state of the patient (i.e., rather than indicating the name of the disease).[3]:80 Prognostic signs always point to the future. Perhaps the most famous prognostic sign is the facies Hippocratica:
"[If the patient's facial] appearance may be described thus: the nose sharp, the eyes sunken, the temples fallen in, the ears cold and drawn in and their lobes distorted, the skin of the face hard, stretched and dry, and the colour of the face pale or dusky.… and if there is no improvement within [a prescribed period of time], it must be realized that this sign portends death."[4]
Anamnestic signs (from anamnēstikós, ἀναμνηστικός, "able to recall to mind"): signs that (taking into account the current state of a patient's body), indicate the past existence of a certain disease or condition.[3]:81 Anamnestic signs always point to the past. (As King (1982) explains, whenever we see a man walking with a particular gait, with one arm paralysed in a particular way, we say "This man has had a stroke"; and, if we see a woman in her late 50s with one arm distorted in a particular way, we say "She had polio as a child".[3]:81)
Diagnostic signs (from diagnōstikós, διαγνωστικός, "able to distinguish"): signs that lead to the recognition and identification of a disease (i.e., they indicate the name of the disease).[3]:81
"'List of eponymously named medical signs"': signs named after people.
Pathognomonic signs (from pathognomonikós, παθογνωμονικός, "skilled in diagnosis", derived from páthos, πάθος, "suffering, disease", and gnṓmon, γνώμον, "judge, indicator"): the particular signs whose presence means, beyond any doubt, that a particular disease is present.[3]:99–100 They represent a marked intensification of a diagnostic sign. (An example would be the palmar xanthomata seen on the hands of people suffering from hyperlipoproteinaemia.) Singular pathognomonic signs are relatively uncommon.
"Symptoms become signs when they permit inference. Ordinarily, one single symptom by itself—such as pain or swelling, or discoloration, or bloody discharge—would not permit any specific inference, but when symptoms occur in clusters and form a pattern, then the aggregate might point to a particular disease. The pathognomonic sign, however, does not need any other manifestation to lead the physician to the correct diagnosis. It constitutes a one-to-one relationship—the sign and the disease are uniquely related. The pathognomonic sign was the "clincher", the datum that established the diagnosis unequivocally."[3]:100
Technological development creating signs detectable only by physicians[edit]
Prior to the nineteenth century there was little difference in the powers of observation between physician and patient. Most medical practice was conducted as a joint co-operative interaction between the physician and his aristocratic patient as equals; this was gradually replaced by a "monolithic consensus of opinion imposed from within the community of medical investigators".[5][6] Whilst each noticed much the same things, the physician had a more informed interpretation of those things: "the physicians knew what the findings meant and the layman did not".[3]:82
Advances in the 19th century[edit]
However, the patient was gradually removed from the medical interaction[5][6][7] due to significant technological advances such as:
The 1808 introduction of the percussion technique, "the process through which "the physician can assess the state of the underlying lung by sensing the character of vibrations by gentle taps on the chest wall [something which] greatly facilitated the diagnosis of pneumonia and other respiratory diseases".[8] The techniques, which had been first described by the Viennese physician Leopold Auenbrugger (1722–1809) in 1761, became far more widely known following the publication of Jean-Nicolas Corvisart's (French) translation of Auenbrugger's (Latin) work in 1808.
The 1819 introduction by René Laennec (1781–1826) of the technique of auscultation (using a stethoscope to listen to the circulatory and respiratory functions of the body). Laennec's publication was translated into English, 1821–1834, by John Forbes.
The 1846 introduction by surgeon John Hutchinson (1811–1861) of the spirometer, an apparatus for assessing the mechanical properties of the lungs via measurements of forced exhalation and forced inhalation. (The recorded lung volumes and air flow rates are used to distinguish between restrictive disease (in which the lung volumes are decreased: e.g., cystic fibrosis) and obstructive diseases (in which the lung volume is normal but the air flow rate is impeded; e.g., emphysema).)
The 1851 invention by Hermann von Helmholtz (1821–1894) of the ophthalmoscope, which allowed physicians to examine the inside of the human eye.
The (c.1870) immediate widespread clinical use of Sir Thomas Clifford Allbutt's (1836-1925) six inch (rather than twelve inch) pocket clinical thermometer, which he had devised in 1867.[9]
The 1882 introduction of bacterian cultures by Robert Koch, initially for the tuberculosis, being the first laboratory test to confirm bacterial infections.
The 1895 clinical use of X-rays which began almost immediately after they had been discovered that year by Wilhelm Conrad Röntgen (1845–1923).
The 1896 introduction of the sphygmomanometer, designed by Scipione Riva-Rocci (1863–1937), to measure blood pressure.
Alteration of the relationship between physician and patient[edit]
The introduction of the techniques of percussion and auscultation into medical practice altered the relationship between physician and patient in a very significant way, specifically because these techniques relied almost entirely upon the physician listening to the sounds of the patient's body.
Not only did this development greatly reduce the patient's capacity to observe and contribute to the process of diagnosis, it also meant that the patient was often instructed to stop talking, and remain silent.
As these sorts of evolutionary changes continued to take place in medical practice, it was increasingly necessary to uniquely identify data that was accessible only to the physician, and to be able to differentiate those observations from others that were also available to the patient, and it just seemed natural to use "signs" for the class of physician-specific data, and "symptoms" for the class of observations available to the patient.
King proposes a more advanced notion; namely, that a sign is something that has meaning, regardless of whether it is observed by the physician or reported by the patient:
The belief that a symptom is a subjective report of the patient, while a sign is something that the physician elicits, is a 20th-century product that contravenes the usage of two thousand years of medicine. In practice, now as always, the physician makes his judgments from the information that he gathers. The modern usage of signs and symptoms emphasizes merely the source of the information, which is not really too important. Far more important is the use that the information serves. If the data, however derived, lead to some inferences and go beyond themselves, those data are signs. If, however, the data remain as mere observations without interpretation, they are symptoms, regardless of their source. Symptoms become signs when they lead to an interpretation. The distinction between information and inference underlies all medical thinking and should be preserved.[3]:89
As tests[edit]
In some senses, the process of diagnosis is always a matter of assessing the likelihood that a given condition is present in the patient. In a patient who presents with haemoptysis (coughing up blood), the haemoptysis is very much more likely to be caused by respiratory disease than by the patient having broken their toe. Each question in the history taking allows the medical practitioner to narrow down their view of the cause of the symptom, testing and building up their hypotheses as they go along.
Examination, which is essentially looking for clinical signs, allows the medical practitioner to see if there is evidence in the patient's body to support their hypotheses about the disease that might be present.
A patient who has given a good story to support a diagnosis of tuberculosis might be found, on examination, to show signs that lead the practitioner away from that diagnosis and more towards sarcoidosis, for example. Examination for signs tests the practitioner's hypotheses, and each time a sign is found that supports a given diagnosis, that diagnosis becomes more likely.
Special tests (blood tests, radiology, scans, a biopsy, etc.) also allow a hypothesis to be tested. These special tests are also said to show signs in a clinical sense. Again, a test can be considered pathognonomic for a given disease, but in that case the test is generally said to be "diagnostic" of that disease rather than pathognonomic. An example would be a history of a fall from a height, followed by a lot of pain in the leg. The signs (a swollen, tender, distorted lower leg) are only very strongly suggestive of a fracture; it might not actually be broken, and even if it is, the particular kind of fracture and its degree of dislocation need to be known, so the practitioner orders an x-ray — and, for example, if the x-ray were to show a fractured tibia, the film would be diagnostic of the fracture.
Examples of signs[edit]
Ascites
Clubbing (deformed nails)
Cough
Death rattle (last moments of life in a person/animal)
Fever
Gynecomastia (excessive breast tissue in males)
Hemoptysis (blood-stained sputum)
Hepatosplenomegaly (enlarged liver and spleen)
Icterus ("jaundice")
Lymphadenopathy (swollen lymph nodes)
Palmar erythema (reddening of hands)
Saliva, excessive (hypersalivation)
Splenomegaly (enlarged spleen)
Weight loss
See also[edit]
Symptom
Stethoscope
Radiologic sign
neurological sign
medical test
biomarker
medical findings, including clinical findings (signs and symptoms) and other laboratory findings.
References[edit]
Jump up ^ "Definition: 'Sign'". Stedman's Medical Dictionary. Lippincott Williams & Wilkins via Medilexicon International Ltd.'s website, medilexicon.org. Retrieved 12 December 2013.
Jump up ^ Stubbe, H. (Henry Stubbes), The Plus Ultra reduced to a Non Plus: Or, A Specimen of some Animadversions upon the Plus Ultra of Mr. Glanvill, wherein sundry Errors of some Virtuosi are discovered, the Credit of the Aristotelians in part Re-advanced; and Enquiries made... (London), 1670, p. 75
^ Jump up to: a b c d e f g h i j k l King, Lester S. (1982). Medical Thinking: A Historical Preface. Princeton, NJ: Princeton University Press. ISBN 0-691-08297-9.
Jump up ^ Chadwick, J. & Mann, W.N.(trans.) (1978). Hippocratic writings. Harmondsworth, UK: Penguin. pp. 170–171. ISBN 0-14-044451-3. CS1 maint: Multiple names: authors list (link)
^ Jump up to: a b Jewson, N. D., "Medical Knowledge and the Patronage System in 18th Century England", Sociology, Vol.8, No.3, (1974), pp. 369–385.
^ Jump up to: a b Jewson, N. D., "The Disappearance of the Sick Man from Medical Cosmology, 1770–1870", Sociology, Vol.10, No.2, (1976), pp. 225–244.
Jump up ^ Tsouyopoulos N (1988). "The mind-body problem in medicine (the crisis of medical anthropology and its historical preconditions)". Hist Philos Life Sci. 10 Suppl: 55–74. PMID 3413276.
Jump up ^ Weatherall, D. (1996). Science and the Quiet Art: The Role of Medical Research in Health Care. New York: W. W. Norton & Company. p. 46. ISBN 0-393-31564-9.
Jump up ^ Allbutt, T.C., "Medical Thermometry", British and Foreign Medico-Chirurgical Review, Vol.45, No.90, (April 1870), pp.429-441; Vo.46, No.91, (July 1870), pp.144-156.
External links[edit]
Who Named It?[1]: eponymous signs.
[show]
v
t
e
Basic medical terms used to describe disease conditions
Medical sign
Symptom
Syndrome
Medical diagnosis
Differential diagnosis
Prognosis
Acute
Chronic
Cure/Remission
Disease
Eponymous disease
Acronym or abbreviation
[show]
Symptoms and signs
[show]
v
t
e
Symptoms and signs relating to the cardiovascular system (R00–R03, 785)
Chest pain
Referred pain
Angina
Aerophagia
Auscultation
Heart sounds
Split S2
S3
S4
Gallop rhythm
Heart murmur
Systolic
Diastolic
Continuous
Pericardial friction rub
Heart click
Bruit
carotid
Pulse
Tachycardia
Bradycardia
Pulsus tardus et parvus
Pulsus paradoxus
doubled
Pulsus bisferiens
Dicrotic pulse
Pulsus bigeminus
Pulsus alternans
Pulse deficit
Vascular disease
Gangrene
Other
Palpitations
Apex beat
Cœur en sabot
Jugular venous pressure
Cannon A waves
Hyperaemia
Shock
Cardiogenic
Hypovolemic
Distributive
Septic
Neurogenic
[show]
v
t
e
Symptoms and signs: cognition, perception, emotional state and behaviour (R40–R46, 780.0–780.5, 781.1)
Cognition
Alteration of
consciousness
Confusion (Delirium)
Somnolence
Obtundation
Stupor
Unconsciousness
Syncope
Coma
Persistent vegetative state
Fainting/Syncope
Carotid sinus syncope
Heat syncope
Vasovagal episode
Other
Amnesia
Anterograde amnesia
Retrograde amnesia
Dizziness
Vertigo
Presyncope/Lightheadedness
Disequilibrium
Convulsion
Emotional state
Anxiety
Irritability
Hostility
Suicidal ideation
Behavior
Verbosity
Russell's sign
Perception/
sensation
disorder
Audition
Olfaction : Anosmia
Hyposmia
Dysosmia
Parosmia
Phantosmia
Hyperosmia
Tactile perception
Taste: Ageusia
Hypogeusia
Dysgeusia
Parageusia
Hypergeusia
Visual perception
Hallucination: Auditory hallucination
[show]
v
t
e
Symptoms and signs: digestive system and abdomen (R10–R19, 787,789)
Upper
Nausea
Vomiting
Heartburn
Aerophagia
Dysphagia
oropharyngeal
esophageal
Odynophagia
Halitosis
Xerostomia
Hypersalivation
Burping
Wet burp
Defaecation
Flatulence
Fecal incontinence
Encopresis
Blood: Fecal occult blood
Rectal tenesmus
Constipation
Obstructed defecation
Diarrhea
Rectal discharge
Psoas sign
Obturator sign
Rovsing's sign
Hamburger sign
Heel tap sign
Aure-Rozanova's sign
Dunphy sign
Alder's sign
Lockwood's sign
Rosenstein's sign
Abdomen
Abdominal pain
Acute abdomen
Colic
Baby colic
Abdominal guarding
Rebound tenderness
Abdominal distension
Bloating
Ascites
Tympanites
Shifting dullness
Bulging flanks
Fluid wave test
Abdominal mass
Hepatosplenomegaly
Hepatomegaly
Splenomegaly
Jaundice
Mallet-Guy sign
Puddle sign
[show]
v
t
e
Symptoms and signs: general / constitutional (R50–R61, 780.6–780.9)
Temperature
heat:
Fever
Fever of unknown origin
Drug-induced fever
Postoperative fever
Hyperhidrosis
e.g., Sleep hyperhidrosis; "sweating"
Hyperpyrexia
Hyperthermia
cold:
Chills
Hypothermia
Aches/pains
Headache
Chronic pain
Cancer pain
Myalgia
Malaise and fatigue
Atrophy
e.g., Muscular atrophy
Debility (or asthenia)
Lassitude
Lethargy
Muscle tremors
Tenderness
Miscellaneous
Flu-like symptoms
[show]
v
t
e
Symptoms and signs: nervous and musculoskeletal systems (R25–R29, 781.0, 781.2–9)
Primarily nervous system
Primarily CNS
Movement disorders
Dyskinesia: Athetosis
Tremor
Gait abnormality
Scissor gait
Cerebellar ataxia
Festinating gait
Marche a petit pas
Propulsive gait
Stomping gait
Spastic gait
Magnetic gait
Lack of coordination
Dyskinesia: Ataxia
Cerebellar ataxia/Dysmetria
Sensory ataxia
Dyssynergia
Dysdiadochokinesia
Asterixis
Other
Abnormal posturing: Opisthotonus
Sensory processing disorder: Hemispatial neglect
Facial weakness
Hyperreflexia
Pronator drift
Primarily PNS
Gait abnormality
Steppage gait
Antalgic gait
Primarily muscular
Movement disorders
Spasm
Trismus
Fasciculation
Fibrillation
Myokymia
Cramp
Gait abnormality
Myopathic gait
Trendelenburg gait
Pigeon gait
Other
Tetany
Meningism
Primarily skeletal
Rachitic rosary
Clubbing
Primarily joint
Joint locking
[show]
v
t
e
Symptoms and signs relating to the respiratory system (R04–R07, 786)
Medical examination and history taking
Auscultation
Stethoscope
Respiratory sounds
Stridor
Wheeze
Crackles
Rhonchi
Stertor
Squawk
Pleural friction rub
Fremitus
Bronchophony
Terminal secretions
Elicited findings
Percussion
Pectoriloquy
Whispered pectoriloquy
Egophony
Breathing
Rate
Apnea
Prematurity
Dyspnea
Hyperventilation
Hypoventilation
Hyperpnea
Tachypnea
Hypopnea
Bradypnea
Pattern
Agonal respiration
Biot's respiration
Cheyne–Stokes respiration
Kussmaul breathing
Ataxic respiration
Other
Respiratory distress
Respiratory arrest
Orthopnea/Platypnea
Trepopnea
Aerophagia
Asphyxia
Breath holding
Mouth breathing
Snoring
Other
Chest pain
In children
Precordial catch syndrome
Pleurisy
Clubbing/Hippocratic fingers (Schamroth's window test)
Cyanosis
Cough
Sputum
Hemoptysis
Epistaxis
Silhouette sign
Post-nasal drip
Hiccup
COPD
Hoover's sign
asthma
Curschmann's spirals
Charcot–Leyden crystals
chronic bronchitis
Reid index
sarcoidosis
Kveim test
pulmonary embolism
Hampton hump
Westermark sign
pulmonary edema
Kerley lines
Hamman's sign
Golden S sign
[show]
v
t
e
Symptoms and signs: skin and subcutaneous tissue (R20–R23, 782)
Disturbances of
skin sensation
Hypoesthesia
Paresthesia
Formication
Hyperesthesia
Hypoalgesia
Hyperalgesia
Circulation
Cyanosis
Pallor/Livedo
Livedo reticularis
Flushing
Petechia
Edema
Peripheral edema
Anasarca
Other
Rash
Desquamation
Induration
Diaphoresis
Mass
Neck mass
Skin
Asboe-Hansen sign
Auspitz's sign
Borsari's sign
Braverman's sign
Crowe sign
Dennie–Morgan fold
Darier's sign
Fitzpatrick's sign
Florid cutaneous papillomatosis
Gottron's sign
Hutchinson's sign
Janeway lesion
Kerr's sign
Koebner's phenomenon
Koplik's spots
Leser-Trelat sign
Nikolsky's sign
Pastia's sign
Russell's sign
Wickham striae
Wolf's isotopic response
Nails
Aldrich-Mees' lines
Beau's lines
Muehrcke's lines
Terry's nails
[show]
v
t
e
Symptoms and signs: Speech and voice / Symptoms involving head and neck (R47–R49, 784)
Aphasias
Acute Aphasias
Expressive aphasia
Receptive aphasia
Conduction aphasia
Anomic aphasia
Global aphasia
Transcortical sensory aphasia
Transcortical motor aphasia
Mixed transcortical aphasia
Progressive Aphasias
Progressive nonfluent aphasia
Semantic dementia
Logopenic progressive aphasia
Speech disturbances
Speech disorder
Developmental verbal dyspraxia/Apraxia of speech
Auditory verbal agnosia
Dysarthria
Schizophasia
Aprosodia/Dysprosody
Specific language impairment
Thought disorder
Pressure of speech
Derailment
Clanging
Circumstantiality
Communication disorders
Developmental dyslexia/Alexia
Agnosia
Astereognosis
Prosopagnosia
Visual agnosia
Gerstmann syndrome
Developmental coordination disorder/Apraxia
Ideomotor apraxia
Dyscalculia/Acalculia
Agraphia
Voice disturbances
Dysphonia/Aphonia
Bogart–Bacall syndrome
Nose
Post-nasal drip
Epistaxis
Mouth
Orofacial pain
Toothache
Galvanic pain
Barodontalgia
Fremitus
Tooth mobility
Bruxism
Trismus
Ageusia
Hypogeusia
Dysgeusia
Parageusia
Hypergeusia
Xerostomia
Halitosis
Drooling
Hypersalivation
Neck
Neck mass
Cervical lymphadenopathy
Other
Headache
Auditory processing disorder
Otalgia
Velopharyngeal inadequacy
Velopharyngeal insufficiency
Hypersensitive gag reflex
Jaw claudication
Hypomimia
[show]
v
t
e
Symptoms and signs relating to endocrine system, nutrition and development (R62–R64, 783)
Weight and appetite
decrease:
Anorexia
Weight loss
Cachexia
Underweight
increase:
Polyphagia
Polydipsia
Orexigenia
Weight gain
Growth
Delayed milestone
Failure to thrive
Short stature
Idiopathic
Thyroid disease
General
Goitre
Graves' disease
Abadie's sign of exophthalmic goiter
Boston's sign
Dalrymple's sign
Stellwag's sign
lid lag
Von Graefe's sign
Griffith's sign
Möbius sign
Hypothyroidism
Queen Anne's sign
Nutrition
Rickets
Harrison's groove
Benedict solution
Metabolic disorders
low calcium
Chvostek sign
Trosseau's sign
low glucose
Whipple's triad
[show]
v
t
e
Symptoms and signs: urinary system (R30–R39, 788)
Pain
Renal colic
Costovertebral angle tenderness
Dysuria
Vesical tenesmus
Control
Urinary incontinence
Enuresis
Diurnal enuresis
Giggling
Nocturnal enuresis
Post-void dribbling
Stress
Urge
Overflow
Urinary retention
Volume
Oliguria
Anuria
Polyuria
Other
Lower urinary tract symptoms
Nocturia
Urinary urgency
Urinary frequency
Extravasation of urine
Extrarenal uremia
Urinoma
Eponymous
Addis count
Brewer infarcts
Murphy's punch sign
Lloyd's sign
Retrieved from "https://en.wikipedia.org/w/index.php?title=Medical_sign&oldid=806442743"
Categories:
Medical signs
Semiotics
Hidden categories:
CS1 maint: Multiple names: authors list
Use dmy dates from April 2017
Navigation menu
Personal tools
Not logged in
Talk
Contributions
Create account
Log in
Namespaces
Article
Talk
Variants
Views
Read
Edit
View history
More
Search
Navigation
Main page
Contents
Featured content
Current events
Random article
Donate to Wikipedia
Wikipedia store
Interaction
Help
About Wikipedia
Community portal
Recent changes
Contact page
Tools
What links here
Related changes
Upload file
Special pages
Permanent link
Page information
Wikidata item
Cite this page
Print/export
Create a book
Download as PDF
Printable version
Languages
العربية
Asturianu
Català
Čeština
Cymraeg
Español
فارسی
Français
Ido
Italiano
עברית
Nederlands
Norsk
Polski
Português
Simple English
Slovenčina
کوردی
Српски / srpski
Srpskohrvatski / српскохрватски
Svenska
தமிழ்
ไทย
Türkçe
Tiếng Việt
中文
Edit links
This page was last edited on 22 October 2017, at 01:46.
Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. By using this site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.
Privacy policy
About Wikipedia
Disclaimers
Contact Wikipedia
Developers
Cookie statement
Mobile view
Enable previews

values: mw-page-base noprint

values: mw-head-base noprint

values: firstHeading firstHeading en

values: siteSub noprint

values: jump-to-nav mw-jump

value: b

value: sup

value: p

values:
/wiki/Lexical_(semiotics)
mw-redirect
Lexical (semiotics)

values:
/wiki/Salience_(semiotics)
mw-redirect
Salience (semiotics)

values: Semiotic theory of Charles Sanders Peirce

values:
/wiki/Commutation_test_(semiotics)
mw-redirect
Commutation test (semiotics)

values:
/wiki/Juri_Lotman
mw-redirect
Juri Lotman

values: float:right;clear:right;width:19.5em;margin:0 0 1.0em 1.0em;background:#f9f9f9;border:1px solid #aaa;padding:0.2em;border-spacing:0.4em 0;text-align:center;line-height:1.4em;font-size:88%

values:
/wiki/Henry_Stubbes
mw-redirect
Henry Stubbes

values:
/wiki/Fatigue_(physical)
mw-redirect
Fatigue (physical)

values:
/wiki/Facies_Hippocratica
mw-redirect
Facies Hippocratica

values: Edit section: Technological development creating signs detectable only by physicians

values: Edit section: Advances in the 19th century

values:
/wiki/Wilhelm_Conrad_R%C3%B6ntgen
mw-redirect
Wilhelm Conrad Röntgen

values: Edit section: Alteration of the relationship between physician and patient

values:
/wiki/Icterus_(medicine)
mw-redirect
Icterus (medicine)

values: border-collapse: collapse; padding: 0; border: 0; background:transparent; width:100%;

values:
/wiki/Neurological_sign
mw-redirect
Neurological sign

values: Category:CS1 maint: Multiple names: authors list

values:
/wiki/PubMed_Identifier
mw-redirect
PubMed Identifier

values:
nofollow
external text
//www.ncbi.nlm.nih.gov/pubmed/3413276

values: -moz-column-width: 30em; -webkit-column-width: 30em; column-width: 30em; list-style-type: decimal;

values:
nofollow
external autonumber
http://www.whonamedit.com/azeponyms.cfm

values: Template:Medical terms to describe disease conditions

values: Template talk:Medical terms to describe disease conditions (page does not exist)

values:
/wiki/Chronic_(medicine)
mw-redirect
Chronic (medicine)

values: border-spacing: 0px; text-align:left;width:auto; margin-left:auto; margin-right:auto;

values: nowraplinks collapsible autocollapse navbox-inner

values: Template:Cardiovascular system symptoms and signs

values: Template talk:Cardiovascular system symptoms and signs

values:
/wiki/Cardiovascular_system
mw-redirect
Cardiovascular system

values: List of ICD-9 codes 780–799: symptoms, signs, and ill-defined conditions

values:
/wiki/Angina_pectoris
mw-redirect
Angina pectoris

values: Template:Cognition, perception, emotional state and behaviour symptoms and signs

values: Template talk:Cognition, perception, emotional state and behaviour symptoms and signs

values:
/wiki/Carotid_sinus_syncope
mw-redirect
Carotid sinus syncope

values:
/wiki/Vasovagal_episode
mw-redirect
Vasovagal episode

values:
/wiki/Emotional_state
mw-redirect
Emotional state

values:
/wiki/Anxiety_(mood)
mw-redirect
Anxiety (mood)

values: Template:Digestive system and abdomen symptoms and signs

values: Template talk:Digestive system and abdomen symptoms and signs

values:
/wiki/Digestive_system
mw-redirect
Digestive system

values:
/wiki/Human_abdomen
mw-redirect
Human abdomen

values:
/wiki/Rebound_tenderness
mw-redirect
Rebound tenderness

values: Template talk:General symptoms and signs

values: ICD-10 Chapter XVIII: Symptoms, signs and abnormal clinical and laboratory findings

values: Template:Nervous and musculoskeletal system symptoms and signs

values: Template talk:Nervous and musculoskeletal system symptoms and signs

values:
/wiki/Movement_disorder
mw-redirect
Movement disorder

values: Template:Respiratory system symptoms and signs

values: Template talk:Respiratory system symptoms and signs

values: Template:Medical records and physical exam

values:
/wiki/Respiratory_distress
mw-redirect
Respiratory distress

values:
/wiki/Chronic_bronchitis
mw-redirect
Chronic bronchitis

values: Template:Skin and subcutaneous tissue symptoms and signs

values: Template talk:Skin and subcutaneous tissue symptoms and signs

values:
/wiki/Gottron%27s_sign
mw-redirect
Gottron's sign

values:
/wiki/Pastia%27s_sign
mw-redirect
Pastia's sign

values: Template:Symptoms involving head and neck

values: Template talk:Symptoms involving head and neck

values:
/wiki/Alexia_(condition)
mw-redirect
Alexia (condition)

values:
/wiki/Galvanic_pain
mw-redirect
Galvanic pain

values: Hypersensitive gag reflex (page does not exist)

values: Template:Symptoms concerning nutrition, metabolism and development

values: Template talk:Symptoms concerning nutrition, metabolism and development

values:
/wiki/Metabolic_disorders
mw-redirect
Metabolic disorders

values: Template:Urinary system symptoms and signs

values: Template talk:Urinary system symptoms and signs

values:
/wiki/Urge_incontinence
mw-redirect
Urge incontinence

values:
/wiki/List_of_eponymous_medical_signs
mw-redirect
List of eponymous medical signs

values:
/wiki/Murphy%27s_punch_sign
mw-redirect
Murphy's punch sign

values: Discussion about edits from this IP address [ctrl-alt-n]

values: A list of edits made from this IP address [ctrl-alt-y]

values: You are encouraged to create an account and log in; however, it is not mandatory

values: You're encouraged to log in; however, it's not mandatory. [ctrl-alt-o]

values:
/wiki/Medical_sign
View the content page [ctrl-alt-c]
c

values: Discussion about the content page [ctrl-alt-t]

values: p-namespaces navigation vectorTabs p-namespaces-label

values:
p-variants
navigation
vectorMenu emptyPortlet
p-variants-label

values: Past revisions of this page [ctrl-alt-h]

values: p-views navigation vectorTabs p-views-label

values:
p-cactions
navigation
vectorMenu emptyPortlet
p-cactions-label

values:
mw-wiki-logo
/wiki/Main_Page
Visit the main page

values:
/wiki/Main_Page
Visit the main page [ctrl-alt-z]
z

values: Featured content – the best of Wikipedia

values: Find background information on current events

values:
/wiki/Special:Random
Load a random article [ctrl-alt-x]
x

values: portal navigation p-navigation p-navigation-label

values: Guidance on how to use and edit Wikipedia

values: About the project, what you can do, where to find things

values: A list of recent changes in the wiki [ctrl-alt-r]

values: portal navigation p-interaction p-interaction-label

values: List of all English Wikipedia pages containing links to this page [ctrl-alt-j]

values: Recent changes in pages linked from this page [ctrl-alt-k]

values:
/wiki/Wikipedia:File_Upload_Wizard
Upload files [ctrl-alt-u]
u

values: A list of all special pages [ctrl-alt-q]

values: Permanent link to this revision of the page

values: Link to connected data repository item [ctrl-alt-g]

values: Printable version of this page [ctrl-alt-p]

values:
uls-settings-trigger
Language settings
0
button
true

values: علامة طبية – Arabic

values: علامت بیماری – Persian

values: סימן (רפואה) – Hebrew

values: نیشانەی پزیشکی – Central Kurdish

values: Знаци болести – Serbian

values: குறி (குறியியல்) – Tamil

values: อาการแสดง – Thai

values:
https://tr.wikipedia.org/wiki/Bulgu
Bulgu – Turkish
tr
tr
interlanguage-link-target

values: mediawiki ltr sitedir-ltr mw-hide-empty-elt ns-0 ns-subject page-Medical_sign rootpage-Medical_sign skin-vector action-view


text:
Mouse button
From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (January 2017) (Learn how and when to remove this template message)
One-button mouse
Three-button mouse
Five-button ergonomic mouse
A mouse button is a microswitch on a computer mouse which can be pressed (“clicked”) to select or interact with an element of a graphical user interface.
The three-button scrollmouse has become the most commonly available design. As of 2007 (and roughly since the late 1990s), users most commonly employ the second button to invoke a contextual menu in the computer's software user interface, which contains options specifically tailored to the interface element over which the pointer currently sits. By default, the primary mouse button sits located on the left-hand side of the mouse, for the benefit of right-handed users; left-handed users can usually reverse this configuration via software.
Contents
1 Design
2 Operation
3 Number of buttons
3.1 Computer
4 Additional buttons
5 Scroll wheel
6 Software environment use
7 References
Design[edit]
In contrast to its motion-tracking mechanism, the mouse's buttons have changed little over the years, varying mostly in shape, number, and placement.
Apple Mighty Mouse with electrocapacitative “buttons”
A mouse click is the action of pressing (i.e. 'clicking', an onomatopoeia) a button to trigger an action, usually in the context of a graphical user interface (GUI). “Clicking” an onscreen button is accomplished by pressing on the real mouse button while the pointer is placed over the onscreen button's icon.
The reason for the clicking noise made is due to the specific switch technology used nearly universally in computer mice. The switch is a subminiature precision snap-action type; the first of such types were the Honeywell MICRO SWITCH products.
Operation[edit]
Double clicking refers to clicking (and, naturally, releasing) a button (often the primary one) twice. Software recognizes both clicks, and if the second occurs within a short time, the action is recognized as a double click.
If the second click is made after the time expires it is considered to be a new, single click. Most modern operating systems and mice drivers allow a user to change the speed of a double click, along with an easy way to test the setting. Some software recognizes three or more clicks, such as progressively selecting a word, sentence, or paragraph in a word processor text page as more clicks are given in a sequence.
With less abstracted software, a mouse button's current state (“mouse up” and “mouse down”) is monitored, allowing for modal operations such as drag and drop.
Number of buttons[edit]
Douglas Engelbart's first mouse had a single button; Xerox PARC soon designed a three-button model, but reduced the count to two for Xerox products. Apple decided on one button for their GUI environments on commercial release in 1983, while most other PC environments standardized on two, and most professional workstation environments used three. Aside from such OEM bundled mice, usually having between one and three buttons, many aftermarket mice have always had five or more, with varying amounts of additional software included to support them.
This state of affairs continued until the late 1990s, when growing support for mice with a scroll wheel after the 1996 introduction of Microsoft's IntelliMouse incidentally made 3-button pointing devices ubiquitous on OEM hardware. The one major holdout, Apple, finally went multi-button in 2005 with their Mighty Mouse, though all Apple laptops would continue to use one-button trackpads until their first buttonless trackpad in 2008.
Computer[edit]
"My friend Marvin Minsky tells me there's great controversy in the artificial intelligence community over how many buttons a mouse should have", Jerry Pournelle wrote in 1983.[1] In the matter of the number of buttons, Engelbart favored the view “as many as possible.” The prototype that popularized the idea of three buttons as standard had that number only because “we could not find anywhere to fit any more switches.”
Those favoring single-button mice argue that a single button is simpler for novice users to understand, and for developers to support. In addition, as a lowest common denominator option, it offers both a path gradual advancement in user sophistication for unfamiliar applications, and a fallback for diverse or malfunctioning hardware. Those favoring multiple-button mice argue that support for a single-button mouse often requires clumsy workarounds in interfaces where a given object may have more than one appropriate action. Several common workarounds exist, and some are specified by the Apple Human Interface Guidelines.
One workaround was the double click, first used on the Lisa, to allow both the “select” and “open” operation to be performed with a single button.
Another workaround has the user hold down one or more keys on the keyboard before pressing the mouse button (typically control on a Macintosh for contextual menus). This has the disadvantage that it requires that both the user's hands be engaged. It also requires that the user perform actions on completely separate devices in concert; that is, holding a key on the keyboard while pressing a button on the mouse. This can be a difficult task for a disabled user, although can be remedied by allowing keys to stick so that they do not need to be held down.
Another involves the press-and-hold technique. In a press-and-hold, the user presses and holds the single button. After a certain period, software perceives the button press not as a single click but as a separate action. This has two drawbacks: first, a slow user may press-and-hold inadvertently. Second, the user must wait for the software to detect the click as a press-and-hold, otherwise the system might interpret the button-depression as a single click. Furthermore, the remedies for these two drawbacks conflict with each other: the longer the lag time, the more the user must wait; and the shorter the lag time, the more likely it becomes that some user will accidentally press-and-hold when meaning to click. Studies have found all of the above workarounds less usable than additional mouse buttons for experienced users.[citation needed]
A workaround common to users of two-button mice in environments designed for three buttons is mouse chording, to simulate a tertiary-click by pressing both buttons simultaneously.
Additional buttons[edit]
Aftermarket manufacturers have long built mice with five or more buttons. Depending on the user's preferences and software environment, the extra buttons may allow forward and backward web-navigation, scrolling through a browser's history, or other functions, including mouse related functions like quick-changing the mouse's resolution/sensitivity. As with similar features in keyboards, however, not all software supports these functions. The additional buttons become especially useful in computer gaming, where quick and easy access to a wide variety of functions (such as macros and DPI changes) can give a player an advantage. Because software can map mouse-buttons to virtually any function, keystroke, application or switch, extra buttons can make working with such a mouse more efficient and easier.
Scroll wheel[edit]
Main article: Scroll wheel
Scrollmice almost always mount their scroll wheels on an internal spring-loaded frame and switch, so that simply pushing down makes them work as an extra button, made easier to do without accidentally spinning it by wheel detents present in most scrollmice. Thus most mice today effectively have three buttons.
Software environment use[edit]
The Macintosh user interface, by design, always has and still does make all functions available with a single-button mouse. Apple's Human Interface Guidelines still specify that other developers need to make all functions available with a single-button mouse as well. Various functions commonly done with additional buttons on other platforms were, when implemented on the Mac by most developers, instead done in conjunction with modifier keys. For instance, contextual menus were most often invoked by “Control Key-click,” a behavior later explicitly adopted by Apple in OS 8's Contextual Menu Manager.
While there has always been a Macintosh aftermarket for mice and other pointing devices with two, three, or more buttons, and extensive configurable support (usually through keyboard emulation) to complement such devices in many major software packages on the platform, it wasn't until Mac OS X shipped that support for multi-button mice was hardcoded. X Window System applications, which Mac OS X can also run, have been developed with the use of two or three-button mice in mind.
While historically, most PC mice provided two buttons, only the primary button was standardized in use for MS-DOS and versions of Windows through 3.1x; support and functionality for additional buttons was application specific. However, in 1992, Borland released Quattro Pro for Windows (QPW), which used the right (or secondary) mouse button to bring up a context menu for the screen object clicked (an innovation previously used on the Xerox Alto, but new to most users). Borland actively promoted the feature, advertising QPW as “The right choice,” and the innovation was widely hailed as intuitive and simple. Other applications quickly followed suit, and the “right-click for properties” gesture was cemented as standard Windows UI behavior after it was implemented throughout Windows 95.
Most machines running Unix or a Unix-like operating system run the X Window System which almost always encourages a three-button mouse. X numbers the buttons by convention. This allows user instructions to apply to mice or pointing devices that do not use conventional button placement. For example, a left-handed user may reverse the buttons, usually with a software setting. With non-conventional button placement, user directions that say “left mouse button” or “right mouse button” are confusing. The ground-breaking Xerox Parc Alto and Dorado computers from the mid-1970s used three-button mice, and each button was assigned a color. Red was used for the left (or primary) button, yellow for the middle (secondary), and blue for the right (meta or tertiary). This naming convention lives on in some Smalltalk environments, such as Squeak, and can be less confusing than the right, middle and left designations.
Acorn's RISC OS based computers necessarily use all three mouse buttons throughout their WIMP based GUI. RISC OS refers to the three buttons (from left to right) as Select, Menu and Adjust. Select functions in the same way as the “Primary” mouse button in other operating systems. Menu will bring up a context-sensitive menu appropriate for the position of the pointer, and this often provides the only means of activating this menu. This menu in most applications equates to the “Application Menu” found at the top of the screen in Mac OS, and underneath the window title under Microsoft Windows. Adjust serves for selecting multiple items in the “Filer” desktop, and for altering parameters of objects within applications – although its exact function usually depends on the programmer.
References[edit]
Jump up ^ Pournelle, Jerry (June 1983). "Zenith Z-100, Epson QX-10, Software Licensing, and the Software Piracy Problem". BYTE. 8 (6). p. 411. Retrieved 20 October 2013.
hide
v
t
e
Basic computer components
Input devices
Keyboard
Image scanner
Microphone
Pointing device
Graphics tablet
Joystick
Light pen
Mouse
Optical
Pointing stick
Touchpad
Touchscreen
Trackball
Refreshable braille display
Sound card
Webcam
Softcam
Video card
Output devices
Monitor
Refreshable braille display
Printer
Speakers
Plotter
Sound card
Video card
Removable
data storage
Optical disc
CD
DVD
Blu-ray
Disk pack
Floppy disk
Memory card
USB flash drive
Computer case
Central processing unit (CPU)
HDD / SSD / SSHD
Motherboard
Network interface controller
Power supply
Random-access memory (RAM)
Fax modem
Expansion card
Ports
Ethernet
FireWire (IEEE 1394)
Parallel port
Serial port
PS/2 port
USB
Thunderbolt
HDMI / DVI / VGA
eSATA
Audio jack
Retrieved from "https://en.wikipedia.org/w/index.php?title=Mouse_button&oldid=838450735"
Categories:
Computer mice
History of human–computer interaction
Video game control methods
American inventions
Hidden categories:
Articles needing additional references from January 2017
All articles needing additional references
All articles with unsourced statements
Articles with unsourced statements from January 2008
Navigation menu
Personal tools
Not logged in
Talk
Contributions
Create account
Log in
Namespaces
Article
Talk
Variants
Views
Read
Edit
View history
More
Search
Navigation
Main page
Contents
Featured content
Current events
Random article
Donate to Wikipedia
Wikipedia store
Interaction
Help
About Wikipedia
Community portal
Recent changes
Contact page
Tools
What links here
Related changes
Upload file
Special pages
Permanent link
Page information
Wikidata item
Cite this page
Print/export
Create a book
Download as PDF
Printable version
Languages
Add links
This page was last edited on 27 April 2018, at 02:46 (UTC).
Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. By using this site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.
Privacy policy
About Wikipedia
Disclaimers
Contact Wikipedia
Developers
Cookie statement
Mobile view
Enable previews

key: html

type: local

value: div

attrs: id class

values: mw-page-base noprint

values: mw-head-base noprint

value: a

attrs: id class lang

values: firstHeading firstHeading en

values: siteSub noprint

attrs: class href

values: mw-jump-link #mw-head

values: mw-jump-link #p-search

value: img

attrs: alt src width height srcset data-file-width data-file-height

attrs: href class

value: td

attrs: href title

values: Help:Introduction to referencing with Wiki Markup/1

value: span

value: i

value: small

values: plainlinks metadata ambox ambox-content ambox-Refimprove

attrs: alt src width height class srcset data-file-width data-file-height

values:
/wiki/Pointer_(computing_WIMP)
mw-redirect
Pointer (computing WIMP)

values: checkbox button toctogglecheckbox toctogglecheckbox display:none

values:
/wiki/Double_click
mw-redirect
Double click

values:
/wiki/Triple_click
mw-redirect
Triple click

values:
/wiki/Quadruple_click
mw-redirect
Quadruple click

values: This claim needs references to reliable sources. (January 2008)

values:
noprint Inline-Template Template-Fact
white-space:nowrap;

values:
/wiki/Computer_gaming
mw-redirect
Computer gaming

values:
/wiki/Control_key_(Macintosh)
mw-redirect
Control key (Macintosh)

values:
/wiki/Xerox_Dorado
mw-redirect
Xerox Dorado

values:
reflist mw-references-wrap
list-style-type: decimal;

values:
/wiki/Solid-state_hybrid_drive
mw-redirect
Solid-state hybrid drive

values: nowraplinks collapsible autocollapse navbox-inner mw-collapsible mw-made-collapsible

values: Category:History of human–computer interaction

values: Category:Articles needing additional references from January 2017

values: Category:All articles needing additional references

values: Category:All articles with unsourced statements

values: Category:Articles with unsourced statements from January 2008

values: Discussion about edits from this IP address [ctrl-alt-n]

values: A list of edits made from this IP address [ctrl-alt-y]

values: You are encouraged to create an account and log in; however, it is not mandatory

values: You're encouraged to log in; however, it's not mandatory. [ctrl-alt-o]

values:
/wiki/Mouse_button
View the content page [ctrl-alt-c]
c

values: Discussion about the content page [ctrl-alt-t]

values: p-namespaces navigation vectorTabs p-namespaces-label

values:
p-variants
navigation
vectorMenu emptyPortlet
p-variants-label

values: Past revisions of this page [ctrl-alt-h]

values: p-views navigation vectorTabs p-views-label

values:
p-cactions
navigation
vectorMenu emptyPortlet
p-cactions-label

values:
mw-wiki-logo
/wiki/Main_Page
Visit the main page

values:
/wiki/Main_Page
Visit the main page [ctrl-alt-z]
z

values: Featured content – the best of Wikipedia

values: Find background information on current events

values: /static/images/wikimedia-button-1.5x.png 1.5x, /static/images/wikimedia-button-2x.png 2x

values: /static/images/poweredby_mediawiki_132x47.png 1.5x, /static/images/poweredby_mediawiki_176x62.png 2x

values:
suggestions
display: none; font-size: 13px;

values: mediawiki ltr sitedir-ltr mw-hide-empty-elt ns-0 ns-subject page-Mouse_button rootpage-Mouse_button skin-vector action-view


text:
Entity–relationship model
From Wikipedia, the free encyclopedia
Jump to: navigation, search
This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (November 2016) (Learn how and when to remove this template message)
An entity–relationship model (ER model for short) describes interrelated things of interest in a specific domain of knowledge. A basic ER model is composed of entity types (which classify the things of interest) and specifies relationships that can exist between instances of those entity types.
An entity–relationship diagram for an MMORPG using Chen's notation.
In software engineering, an ER model is commonly formed to represent things that a business needs to remember in order to perform business processes. Consequently, the ER model becomes an abstract data model, that defines a data or information structure which can be implemented in a database, typically a relational database.
Entity–relationship modeling was developed for database design by Peter Chen and published in a 1976 paper.[1] However, variants of the idea existed previously.[2] Some ER models show super and subtype entities connected by generalization-specialization relationships,[3] and an ER model can be used also in the specification of domain-specific ontologies.
Contents
[hide]
1 Introduction
2 Entity–relationship modeling
2.1 Mapping natural language
2.2 Relationships, roles and cardinalities
2.3 Role naming
2.4 Cardinalities
2.5 Crow's foot notation
2.6 Model usability issues
3 Entity–relationships and semantic modeling
3.1 Semantic model
3.2 Extension model
3.3 Entity–relationship origins
3.3.1 Philosophical alignment
4 Limitations
5 See also
6 References
7 Further reading
8 External links
Introduction[edit]
An entity–relationship model is usually the result of systematic analysis to define and describe what is important to processes in an area of a business. It does not define the business processes; it only presents a business data schema in graphical form. It is usually drawn in a graphical form as boxes (entities) that are connected by lines (relationships) which express the associations and dependencies between entities. An ER model can also be expressed in a verbal form, for example: one building may be divided into zero or more apartments, but one apartment can only be located in one building.
Entities may be characterized not only by relationships, but also by additional properties (attributes), which include identifiers called "primary keys". Diagrams created to represent attributes as well as entities and relationships may be called entity-attribute-relationship diagrams, rather than entity–relationship models.
An ER model is typically implemented as a database. In a simple relational database implementation, each row of a table represents one instance of an entity type, and each field in a table represents an attribute type. In a relational database a relationship between entities is implemented by storing the primary key of one entity as a pointer or "foreign key" in the table of another entity
There is a tradition for ER/data models to be built at two or three levels of abstraction. Note that the conceptual-logical-physical hierarchy below is used in other kinds of specification, and is different from the three schema approach to software engineering.
Conceptual data model
This is the highest level ER model in that it contains the least granular detail but establishes the overall scope of what is to be included within the model set. The conceptual ER model normally defines master reference data entities that are commonly used by the organization. Developing an enterprise-wide conceptual ER model is useful to support documenting the data architecture for an organization.
A conceptual ER model may be used as the foundation for one or more logical data models (see below). The purpose of the conceptual ER model is then to establish structural metadata commonality for the master data entities between the set of logical ER models. The conceptual data model may be used to form commonality relationships between ER models as a basis for data model integration.
Logical data model
A logical ER model does not require a conceptual ER model, especially if the scope of the logical ER model includes only the development of a distinct information system. The logical ER model contains more detail than the conceptual ER model. In addition to master data entities, operational and transactional data entities are now defined. The details of each data entity are developed and the relationships between these data entities are established. The logical ER model is however developed independently of the specific database management system into which it can be implemented.
Physical data model
One or more physical ER models may be developed from each logical ER model. The physical ER model is normally developed to be instantiated as a database. Therefore, each physical ER model must contain enough detail to produce a database and each physical ER model is technology dependent since each database management system is somewhat different.
The physical model is normally instantiated in the structural metadata of a database management system as relational database objects such as database tables, database indexes such as unique key indexes, and database constraints such as a foreign key constraint or a commonality constraint. The ER model is also normally used to design modifications to the relational database objects and to maintain the structural metadata of the database.
The first stage of information system design uses these models during the requirements analysis to describe information needs or the type of information that is to be stored in a database. The data modeling technique can be used to describe any ontology (i.e. an overview and classifications of used terms and their relationships) for a certain area of interest. In the case of the design of an information system that is based on a database, the conceptual data model is, at a later stage (usually called logical design), mapped to a logical data model, such as the relational model; this in turn is mapped to a physical model during physical design. Note that sometimes, both of these phases are referred to as "physical design."
Entity–relationship modeling[edit]
Two related entities
An entity with an attribute
A relationship with an attribute
Primary key
An entity may be defined as a thing capable of an independent existence that can be uniquely identified. An entity is an abstraction from the complexities of a domain. When we speak of an entity, we normally speak of some aspect of the real world that can be distinguished from other aspects of the real world.[4]
An entity is a thing that exists either physically or logically. An entity may be a physical object such as a house or a car (they exist physically), an event such as a house sale or a car service, or a concept such as a customer transaction or order (they exist logically—as a concept). Although the term entity is the one most commonly used, following Chen we should really distinguish between an entity and an entity-type. An entity-type is a category. An entity, strictly speaking, is an instance of a given entity-type. There are usually many instances of an entity-type. Because the term entity-type is somewhat cumbersome, most people tend to use the term entity as a synonym for this term.
Entities can be thought of as nouns. Examples: a computer, an employee, a song, a mathematical theorem, etc.
A relationship captures how entities are related to one another. Relationships can be thought of as verbs, linking two or more nouns. Examples: an owns relationship between a company and a computer, a supervises relationship between an employee and a department, a performs relationship between an artist and a song, a proves relationship between a mathematician and a conjecture, etc.
The model's linguistic aspect described above is utilized in the declarative database query language ERROL, which mimics natural language constructs. ERROL's semantics and implementation are based on reshaped relational algebra (RRA), a relational algebra that is adapted to the entity–relationship model and captures its linguistic aspect.
Entities and relationships can both have attributes. Examples: an employee entity might have a Social Security Number (SSN) attribute, while a proved relationship may have a date attribute.
Every entity (unless it is a weak entity) must have a minimal set of uniquely identifying attributes, which is called the entity's primary key.
Entity–relationship diagrams don't show single entities or single instances of relations. Rather, they show entity sets(all entities of the same entity type) and relationship sets(all relationships of the same relationship type). Examples: a particular song is an entity; the collection of all songs in a database is an entity set; the eaten relationship between a child and her lunch is a single relationship; the set of all such child-lunch relationships in a database is a relationship set. In other words, a relationship set corresponds to a relation in mathematics, while a relationship corresponds to a member of the relation.
Certain cardinality constraints on relationship sets may be indicated as well.
Mapping natural language[edit]
Chen proposed the following "rules of thumb" for mapping natural language descriptions into ER diagrams: "English, Chinese and ER diagrams" by Peter Chen.
English grammar structure
ER structure
Common noun Entity type
Proper noun Entity
Transitive verb Relationship type
Intransitive verb Attribute type
Adjective Attribute for entity
Adverb Attribute for relationship
Physical view show how data is actually stored.
Relationships, roles and cardinalities[edit]
In Chen's original paper he gives an example of a relationship and its roles. He describes a relationship "marriage" and its two roles "husband" and "wife".
A person plays the role of husband in a marriage (relationship) and another person plays the role of wife in the (same) marriage. These words are nouns. That is no surprise; naming things requires a noun.
Chen's terminology has also been applied to earlier ideas. The lines, arrows and crow's-feet of some diagrams owes more to the earlier Bachman diagrams than to Chen's relationship diagrams.
Another common extension to Chen's model is to "name" relationships and roles as verbs or phrases.
Role naming[edit]
It has also become prevalent to name roles with phrases such as is the owner of and is owned by. Correct nouns in this case are owner and possession. Thus person plays the role of owner and car plays the role of possession rather than person plays the role of, is the owner of, etc.
The use of nouns has direct benefit when generating physical implementations from semantic models. When a person has two relationships with car then it is possible to generate names such as owner_person and driver_person, which are immediately meaningful.[5]
Cardinalities[edit]
Modifications to the original specification can be beneficial. Chen described look-across cardinalities. As an aside, the Barker–Ellis notation, used in Oracle Designer, uses same-side for minimum cardinality (analogous to optionality) and role, but look-across for maximum cardinality (the crows foot).[clarification needed]
In Merise,[6] Elmasri & Navathe[7] and others[8] there is a preference for same-side for roles and both minimum and maximum cardinalities. Recent researchers (Feinerer,[9] Dullea et al.[10]) have shown that this is more coherent when applied to n-ary relationships of order greater than 2.
In Dullea et al. one reads "A 'look across' notation such as used in the UML does not effectively represent the semantics of participation constraints imposed on relationships where the degree is higher than binary."
In Feinerer it says "Problems arise if we operate under the look-across semantics as used for UML associations. Hartmann[11] investigates this situation and shows how and why different transformations fail." (Although the "reduction" mentioned is spurious as the two diagrams 3.4 and 3.5 are in fact the same) and also "As we will see on the next few pages, the look-across interpretation introduces several difficulties that prevent the extension of simple mechanisms from binary to n-ary associations."
Various methods of representing the same one to many relationship. In each case, the diagram shows the relationship between a person and a place of birth: each person must have been born at one, and only one, location, but each location may have had zero or more people born at it.
Two related entities shown using Crow's Foot notation. In this example, an optional relationship is shown between Artist and Song; the symbols closest to the song entity represents "zero, one, or many", whereas a song has "one and only one" Artist. The former is therefore read as, an Artist (can) perform(s) "zero, one, or many" song(s).
Chen's notation for entity–relationship modeling uses rectangles to represent entity sets, and diamonds to represent relationships appropriate for first-class objects: they can have attributes and relationships of their own. If an entity set participates in a relationship set, they are connected with a line.
Attributes are drawn as ovals and are connected with a line to exactly one entity or relationship set.
Cardinality constraints are expressed as follows:
a double line indicates a participation constraint, totality or surjectivity: all entities in the entity set must participate in at least one relationship in the relationship set;
an arrow from entity set to relationship set indicates a key constraint, i.e. injectivity: each entity of the entity set can participate in at most one relationship in the relationship set;
a thick line indicates both, i.e. bijectivity: each entity in the entity set is involved in exactly one relationship.
an underlined name of an attribute indicates that it is a key: two different entities or relationships with this attribute always have different values for this attribute.
Attributes are often omitted as they can clutter up a diagram; other diagram techniques often list entity attributes within the rectangles drawn for entity sets.
Related diagramming convention techniques:
Bachman notation
Barker's notation
EXPRESS
IDEF1X
Martin notation
(min, max)-notation of Jean-Raymond Abrial in 1974
UML class diagrams
Merise
Object-role modeling
Crow's foot notation[edit]
Crow's foot notation, the beginning of which dates back to an article by Gordon Everest,[12] is used in Barker's Notation, Structured Systems Analysis and Design Method (SSADM) and information engineering. Crow's foot diagrams represent entities as boxes, and relationships as lines between the boxes. Different shapes at the ends of these lines represent the cardinality of the relationship.
Crow's foot notation was used in the consultancy practice CACI. Many of the consultants at CACI (including Richard Barker) subsequently moved to Oracle UK, where they developed the early versions of Oracle's CASE tools, introducing the notation to a wider audience.
With this notation, relationships cannot have attributes. Where necessary, relationships are promoted to entities in their own right: for example, if it is necessary to capture where and when an artist performed a song, a new entity "performance" is introduced (with attributes reflecting the time and place), and the relationship of an artist to a song becomes an indirect relationship via the performance (artist-performs-performance, performance-features-song).
Model usability issues[edit]
This section needs expansion with: fan trap causes. You can help by adding to it. (February 2018)
In using a modeled database, users can encounter two well known issues where the returned results mean something other than the results assumed by the query author.
The first is the 'fan trap'. It occurs with a (master) table that links to multiple tables in a one-to-many relationship. The issue derives its name from the way the model looks when it's drawn in an entity–relationship diagram: the linked tables 'fan out' from the master table. This type of model looks similar to a star schema, a type of model used in data warehouses. When trying to calculate sums over aggregates using standard SQL over the master table, unexpected (and incorrect) results . The solution is to either adjust the model or the SQL. This issue occurs mostly in databases for decision support systems, and software that queries such systems sometimes includes specific methods for handling this issue.
The second issue is a 'chasm trap'. A chasm trap occurs when a model suggests the existence of a relationship between entity types, but the pathway does not exist between certain entity occurrences. For example, a Building has one-or-more Rooms, that hold zero-or-more Computers. One would expect to be able to query the model to see all the Computers in the Building. However, Computers not currently assigned to a Room (because they are under repair or somewhere else) are not shown on the list. Another relation between Building and Computers is needed to capture all the computers in the building. This last modelling issue is the result of a failure to capture all the relationships that exist in the real world in the model. See Entity-Relationship Modelling 2 for details.
Entity–relationships and semantic modeling[edit]
Semantic model[edit]
A semantic model is a model of concepts, it is sometimes called a "platform independent model". It is an intensional model. At the latest since Carnap, it is well known that:[13]
"...the full meaning of a concept is constituted by two aspects, its intension and its extension. The first part comprises the embedding of a concept in the world of concepts as a whole, i.e. the totality of all relations to other concepts. The second part establishes the referential meaning of the concept, i.e. its counterpart in the real or in a possible world".
Extension model[edit]
An extensional model is one that maps to the elements of a particular methodology or technology, and is thus a "platform specific model". The UML specification explicitly states that associations in class models are extensional and this is in fact self-evident by considering the extensive array of additional "adornments" provided by the specification over and above those provided by any of the prior candidate "semantic modelling languages"."UML as a Data Modeling Notation, Part 2"
Entity–relationship origins[edit]
Peter Chen, the father of ER modeling said in his seminal paper:
"The entity-relationship model adopts the more natural view that the real world consists of entities and relationships. It incorporates some of the important semantic information about the real world." [1]
In his original 1976 article Chen explicitly contrasts entity–relationship diagrams with record modelling techniques:
"The data structure diagram is a representation of the organization of records and is not an exact representation of entities and relationships."
Several other authors also support Chen's program:[14] [15] [16] [17] [18]
Philosophical alignment[edit]
Chen is in accord with philosophic and theoretical traditions from the time of the Ancient Greek philosophers: Socrates, Plato and Aristotle (428 BC) through to modern epistemology, semiotics and logic of Peirce, Frege and Russell.
Plato himself associates knowledge with the apprehension of unchanging Forms (The forms, according to Socrates, are roughly speaking archetypes or abstract representations of the many types of things, and properties) and their relationships to one another.
Limitations[edit]
ER assume information content that can readily be represented in a relational database. They describe only a relational structure for this information.
They are inadequate for systems in which the information cannot readily be represented in relational form[citation needed], such as with semi-structured data.
For many systems, possible changes to information contained are nontrivial and important enough to warrant explicit specification.
Some[who?] authors have extended ER modeling with constructs to represent change, an approach supported by the original author;[19] an example is Anchor Modeling. An alternative is to model change separately, using a process modeling technique. Additional techniques can be used for other aspects of systems. For instance, ER models roughly correspond to just 1 of the 14 different modeling techniques offered by UML.
Even where it is suitable in principle, ER modeling is rarely used as a separate activity. One reason for this is today's abundance of tools to support diagramming and other design support directly on relational database management systems. These tools can readily extract database diagrams that are very close to ER diagrams from existing databases, and they provide alternative views on the information contained in such diagrams.
In a survey, Brodie and Liu[20] could not find a single instance of entity–relationship modeling inside a sample of ten Fortune 100 companies. Badia and Lemire[21] blame this lack of use on the lack of guidance but also on the lack of benefits, such as lack of support for data integration.
The enhanced entity–relationship model (EER modeling) introduces several concepts not in ER modeling, but are closely related to object-oriented design, like is-a relationships.
For modelling temporal databases, numerous ER extensions have been considered.[22] Similarly, the ER model was found unsuitable for multidimensional databases (used in OLAP applications); no dominant conceptual model has emerged in this field yet, although they generally revolve around the concept of OLAP cube (also known as data cube within the field).[23]
See also[edit]
Associative entity
Concept map
Database design
Data structure diagram
Enhanced entity–relationship model
Enterprise architecture framework
Value range structure diagrams
Comparison of data modeling tools
Ontology
Object-role modeling
Three schema approach
Structured-Entity-Relationship-Model
Schema-agnostic Databases
References[edit]
^ Jump up to: a b Chen, Peter (March 1976). "The Entity-Relationship Model - Toward a Unified View of Data". ACM Transactions on Database Systems. 1 (1): 9–36. doi:10.1145/320434.320440.
Jump up ^ A.P.G. Brown, "Modelling a Real-World System and Designing a Schema to Represent It", in Douque and Nijssen (eds.), Data Base Description, North-Holland, 1975, ISBN 0-7204-2833-5.
Jump up ^ “Designing a Logical Database: Supertypes and Subtypes”
Jump up ^ Beynon-Davies, Paul (2004). Database Systems. Basingstoke, UK: Palgrave: Houndmills. ISBN 1403916012.
Jump up ^ Thomas Basboell: Motion and society. On meaningfulness of concepts
Jump up ^ Hubert Tardieu, Arnold Rochfeld and René Colletti La methode MERISE: Principes et outils (Paperback - 1983)
Jump up ^ Elmasri, Ramez, B. Shamkant, Navathe, Fundamentals of Database Systems, third ed., Addison-Wesley, Menlo Park, CA, USA, 2000.
Jump up ^ ER 2004 : 23rd International Conference on Conceptual Modeling, Shanghai, China, November 8-12, 2004
Jump up ^ A Formal Treatment of UML Class Diagrams as an Efficient Method for Configuration Management 2007
Jump up ^ James Dullea, Il-Yeol Song, Ioanna Lamprou - An analysis of structural validity in entity-relationship modeling 2002
Jump up ^ Hartmann, Sven. "Reasoning about participation constraints and Chen's constraints". Proceedings of the 14th Australasian database conference-Volume 17. Australian Computer Society, Inc., 2003.
Jump up ^ G. Everest, "BASIC DATA STRUCTURE MODELS EXPLAINED WITH A COMMON EXAMPLE", in Computing Systems 1976, Proceedings Fifth Texas Conference on Computing Systems, Austin,TX, 1976 October 18-19, pages 39-46. (Long Beach, CA: IEEE Computer Society Publications Office).
Jump up ^ http://wenku.baidu.com/view/8048e7bb1a37f111f1855b22.html
Jump up ^ Kent in "Data and Reality" :
"One thing we ought to have clear in our minds at the outset of a modelling endeavour is whether we are intent on describing a portion of "reality" (some human enterprise) or a data processing activity."
Jump up ^ Abrial in "Data Semantics" : "... the so called "logical" definition and manipulation of data are still influenced (sometimes unconsciously) by the "physical" storage and retrieval mechanisms currently available on computer systems."
Jump up ^ Stamper: "They pretend to describe entity types, but the vocabulary is from data processing: fields, data items, values. Naming rules don't reflect the conventions we use for naming people and things; they reflect instead techniques for locating records in files."
Jump up ^ In Jackson's words: "The developer begins by creating a model of the reality with which the system is concerned, the reality that furnishes its [the system's] subject matter ..."
Jump up ^ Elmasri, Navathe: "The ER model concepts are designed to be closer to the user’s perception of data and are not meant to describe the way in which data will be stored in the computer."
Jump up ^ P. Chen. Suggested research directions for a new frontier: Active conceptual modeling. ER 2006, volume 4215 of Lecture Notes in Computer Science, pages 1–4. Springer Berlin / Heidelberg, 2006.
Jump up ^ The power and limits of relational technology in the age of information ecosystems. On The Move Federated Conferences, 2010.
Jump up ^ A. Badia and D. Lemire. A call to arms: revisiting database design. Citeseerx,
Jump up ^ Gregersen, Heidi; Jensen, Christian S. (1999). "Temporal Entity-Relationship models—a survey". IEEE Transactions on Knowledge and Data Engineering. 11 (3): 464–497. CiteSeerX 10.1.1.1.2497  .
Jump up ^ RICCARDO TORLONE (2003). "Conceptual Multidimensional Models". In Maurizio Rafanelli. Multidimensional Databases: Problems and Solutions (PDF). Idea Group Inc (IGI). ISBN 978-1-59140-053-0.
Further reading[edit]
Chen, Peter (2002). "Entity-Relationship Modeling: Historical Events, Future Trends, and Lessons Learned" (PDF). Software pioneers. Springer-Verlag. pp. 296–310. ISBN 3-540-43081-4.
Barker, Richard (1990). CASE Method: Entity Relationship Modelling. Addison-Wesley. ISBN 0201416964.
Barker, Richard (1990). CASE Method: Tasks and Deliverables. Addison-Wesley. ISBN 0201416972.
Mannila, Heikki; Räihä, Kari-Jouko (1992). The Design of Relational Databases. Addison-Wesley. ISBN 0201565234.
Thalheim, Bernhard (2000). Entity-Relationship Modeling: Foundations of Database Technology. Springer. ISBN 978-3-540-65470-4.
Bagui, Sikha; Earp, Richard (2011). Database Design Using Entity-Relationship Diagrams (2nd ed.). CRC Press. ISBN 978-1-4398-6176-9.
External links[edit]
Wikimedia Commons has media related to Entity-relationship models.
"The Entity Relationship Model: Toward a Unified View of Data"
Entity Relationship Modelling
Logical Data Structures (LDSs) - Getting started by Tony Drewry.
Crow's Foot Notation
Kinds of Data Models -- and How to Name Them presentation by David Hay
[show]
v
t
e
Database models
Common models
Flat
Hierarchical
Dimensional
Network
Relational
Entity–relationship
Enhanced
Graph
Object-oriented
Entity–attribute–value
Other models
Associative
Correlational
Multidimensional
Array
Semantic
Star schema
XML database
Implementations
Flat file
Column-oriented
Document-oriented
Object-relational
Deductive
Temporal
XML data store
Key-value store
Triplestore
[show]
v
t
e
Data model
Main
Architecture
Modeling
Structure
Schemas
Conceptual
Logical
Physical
Types
Database
Data structure diagram
Entity–relationship model (enhanced)
Geographic
Generic
Semantic
Related models
Data flow diagram
Information model
Object model
Object-role modeling
Unified Modeling Language
See also
Database design
Business process modeling
Core architecture data model
Enterprise modelling
Function model
Process modeling
XML schema
Data Format Description Language
[show]
v
t
e
Database
Main
Requirements
Theory
Models
Database management system
Machine
Server
Application
Connection
datasource
DSN
Administrator
Lock
Types
Tools
Languages
Data definition
Data manipulation
Query
information retrieval
Security
Activity monitoring
Audit
Forensics
Negative database
Design
Entities and relationships (and Enhanced notation)
Normalization
Refactoring
Programming
Abstraction layer
Object-relational mapping
Management
Virtualization
Tuning
caching
Migration
Preservation
Integrity
See also
Database-centric architecture
Intelligent database
Two-phase locking
Locks with ordered sharing
Load file
Publishing
Halloween Problem
Log shipping
Book
Category
WikiProject
[show]
v
t
e
Software engineering
Fields
Computer programming
Requirements engineering
Software deployment
Software design
Software maintenance
Software testing
Systems analysis
Formal methods
Concepts
Data modeling
Enterprise architecture
Functional specification
Modeling language
Orthogonality
Programming paradigm
Software
Software archaeology
Software architecture
Software configuration management
Software development methodology
Software development process
Software quality
Software quality assurance
Software verification and validation
Structured analysis
Orientations
Agile
Aspect-oriented
Object orientation
Ontology
Service orientation
SDLC
Models
Developmental
Agile
EUP
Executable UML
Incremental model
Iterative model
Prototype model
RAD
UP
Scrum
Spiral model
V-Model
Waterfall model
XP
Other
SPICE
CMMI
Data model
ER model
Function model
Information model
Metamodeling
Object model
Systems model
View model
Languages
IDEF
UML
USL
SysML
Software
engineers
Victor Basili
Kent Beck
Grady Booch
Fred Brooks
Barry Boehm
Peter Chen
Danese Cooper
Ward Cunningham
Tom DeMarco
Edsger W. Dijkstra
Delores M. Etter
Martin Fowler
Adele Goldstine
Margaret Hamilton
C. A. R. Hoare
Lois Haibt
Mary Jean Harrold
Grace Hopper
Watts Humphrey
Michael A. Jackson
Ivar Jacobson
Alan Kay
Nancy Leveson
Stephen J. Mellor
Bertrand Meyer
David Parnas
Trygve Reenskaug
Winston W. Royce
James Rumbaugh
Mary Shaw
Peri Tarr
Elaine Weyuker
Niklaus Wirth
Edward Yourdon
Related fields
Computer science
Computer engineering
Project management
Risk management
Systems engineering
Category
Commons
Authority control
LCCN: sh00009200
Retrieved from "https://en.wikipedia.org/w/index.php?title=Entity–relationship_model&oldid=823522540"
Categories:
Data modeling diagrams
Entity–relationship model
Data modeling languages
Hidden categories:
Articles needing additional references from November 2016
All articles needing additional references
Wikipedia articles needing clarification from April 2012
Articles to be expanded from February 2018
All articles to be expanded
Articles using small message boxes
All articles with unsourced statements
Articles with unsourced statements from July 2016
All articles with specifically marked weasel-worded phrases
Articles with specifically marked weasel-worded phrases from June 2012
Wikipedia articles with LCCN identifiers
Navigation menu
Personal tools
Not logged in
Talk
Contributions
Create account
Log in
Namespaces
Article
Talk
Variants
Views
Read
Edit
View history
More
Search
Navigation
Main page
Contents
Featured content
Current events
Random article
Donate to Wikipedia
Wikipedia store
Interaction
Help
About Wikipedia
Community portal
Recent changes
Contact page
Tools
What links here
Related changes
Upload file
Special pages
Permanent link
Page information
Wikidata item
Cite this page
Print/export
Create a book
Download as PDF
Printable version
In other projects
Wikimedia Commons
Languages
العربية
Català
Čeština
Deutsch
Ελληνικά
Español
فارسی
Français
한국어
Bahasa Indonesia
Italiano
עברית
Қазақша
Latviešu
Lumbaart
Bahasa Melayu
Nederlands
日本語
Polski
Português
Română
Русский
Simple English
Slovenščina
Српски / srpski
Suomi
தமிழ்
ไทย
Türkçe
Українська
中文
22 more
Edit links
This page was last edited on 1 February 2018, at 19:37.
Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. By using this site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.
Privacy policy
About Wikipedia
Disclaimers
Contact Wikipedia
Developers
Cookie statement
Mobile view
Enable previews

values: mw-page-base noprint

values: mw-head-base noprint

values: firstHeading firstHeading en

values: siteSub noprint

values: jump-to-nav mw-jump

values: Help:Introduction to referencing with Wiki Markup/1

value: tr

values: plainlinks metadata ambox ambox-content ambox-Refimprove

values:
/wiki/Ontology_(computer_science)
mw-redirect
Ontology (computer science)

values:
/wiki/Three_schema_approach
mw-redirect
Three schema approach

values:
/wiki/Conceptual_data_model
mw-redirect
Conceptual data model

values:
/wiki/Database_management_system
mw-redirect
Database management system

values:
/wiki/Database_table
mw-redirect
Database table

values:
/wiki/Foreign_key_constraint
mw-redirect
Foreign key constraint

values:
/wiki/Universe_of_discourse
mw-redirect
Universe of discourse

values: Edit section: Entity–relationship modeling

attrs: alt src width height class data-file-width data-file-height

values:
/wiki/Declarative_programming_language
mw-redirect
Declarative programming language

values:
/wiki/Relation_(mathematics)
mw-redirect
Relation (mathematics)

values:
/wiki/Common_noun
mw-redirect
Common noun

values: Edit section: Relationships, roles and cardinalities

values: Look-across cardinality (page does not exist)

values: The text near this tag may need clarification or removal of jargon. (April 2012)

values:
noprint Inline-Template
margin-left:0.1em; white-space:nowrap;

values:
/wiki/First-class_object
mw-redirect
First-class object

values:
/wiki/Total_relation
mw-redirect
Total relation

values:
/wiki/Injective_relation
mw-redirect
Injective relation

values:
/wiki/Bachman_diagram
mw-redirect
Bachman diagram

values:
/wiki/Barker%27s_Notation
mw-redirect
Barker's Notation

values: Structured Systems Analysis and Design Method

values: plainlinks metadata ambox mbox-small-left ambox-content

values:
nofollow
external text
http://db.grussell.org/section005.html

values: Edit section: Entity–relationships and semantic modeling

values:
nofollow
external text
http://www.tdan.com/view-articles/8589

values: Edit section: Entity–relationship origins

values: This claim needs references to reliable sources. (July 2016)

values:
noprint Inline-Template Template-Fact
white-space:nowrap;

values: The material near this tag possibly uses too-vague attribution or weasel words. (June 2012)

values: Wikipedia:Manual of Style/Words to watch

values:
/wiki/Anchor_Modeling
mw-redirect
Anchor Modeling

values:
/wiki/Multidimensional_database
mw-redirect
Multidimensional database

values:
/wiki/Schema-agnostic_Databases
mw-redirect
Schema-agnostic Databases

values:
nofollow
external text
//doi.org/10.1145%2F320434.320440

values:
nofollow
external text
http://www.bkent.net/Doc/darxrp.htm

values:
/wiki/Jackson_Structured_Programming
mw-redirect
Jackson Structured Programming

attrs: alt src title width height srcset data-file-width data-file-height

values: nowraplinks collapsible autocollapse navbox-inner

values:
/wiki/Physical_schema
mw-redirect
Physical schema

values:
/wiki/Data_Source_Name
mw-redirect
Data Source Name

values:
/wiki/Lock_(database)
mw-redirect
Lock (database)

values:
/wiki/Database_integrity
mw-redirect
Database integrity

values: nowraplinks hlist collapsible autocollapse navbox-inner

values: Category:Articles needing additional references from November 2016

values: Category:All articles needing additional references

values: Category:Wikipedia articles needing clarification from April 2012

values: Category:Articles to be expanded from February 2018

values: Category:Articles using small message boxes

values: Category:All articles with unsourced statements

values: Category:Articles with unsourced statements from July 2016

values: Category:All articles with specifically marked weasel-worded phrases

values: Category:Articles with specifically marked weasel-worded phrases from June 2012

values: Category:Wikipedia articles with LCCN identifiers

values: Discussion about edits from this IP address [ctrl-alt-n]

values: A list of edits made from this IP address [ctrl-alt-y]

values: You are encouraged to create an account and log in; however, it is not mandatory

values:
/wiki/Entity%E2%80%93relationship_model
View the content page [ctrl-alt-c]
c

values:
/wiki/Special:Random
Load a random article [ctrl-alt-x]
x

values: portal navigation p-navigation p-navigation-label

values: Guidance on how to use and edit Wikipedia

values: About the project, what you can do, where to find things

values: A list of recent changes in the wiki [ctrl-alt-r]

values: portal navigation p-interaction p-interaction-label

values: List of all English Wikipedia pages containing links to this page [ctrl-alt-j]

values: Recent changes in pages linked from this page [ctrl-alt-k]

values:
/wiki/Wikipedia:File_Upload_Wizard
Upload files [ctrl-alt-u]
u

values: A list of all special pages [ctrl-alt-q]

values: Permanent link to this revision of the page

values: Link to connected data repository item [ctrl-alt-g]

values: Printable version of this page [ctrl-alt-p]

values: portal navigation p-wikibase-otherprojects p-wikibase-otherprojects-label

values: طريقة الكيانات والعلاقات – Arabic

values:
interlanguage-link interwiki-ca
display: none;

values:
interlanguage-link interwiki-cs
display: none;

values: Μοντέλο Οντοτήτων-Συσχετίσεων – Greek

values:
interlanguage-link interwiki-el
display: none;

values: مدل موجودیت–رابطه – Persian

values:
interlanguage-link interwiki-fa
display: none;

values: 개체-관계 모델 – Korean

values:
interlanguage-link interwiki-ko
display: none;

values:
interlanguage-link interwiki-it
display: none;

values: מודל ישויות קשרים – Hebrew

values:
interlanguage-link interwiki-he
display: none;

values: Нысан-байланыс моделі – Kazakh

values:
interlanguage-link interwiki-kk
display: none;

values:
interlanguage-link interwiki-lv
display: none;

values:
interlanguage-link interwiki-lmo
display: none;

values:
interlanguage-link interwiki-nl
display: none;

values: 実体関連モデル – Japanese

values:
interlanguage-link interwiki-ja
display: none;

values:
interlanguage-link interwiki-pl
display: none;

values: Modelo entidade relacionamento – Portuguese

values:
interlanguage-link interwiki-ro
display: none;

values: Entity-relationship model – Simple English

values:
interlanguage-link interwiki-simple
display: none;

values:
interlanguage-link interwiki-sl
display: none;

values: Модел објекти-везе – Serbian

values:
interlanguage-link interwiki-sr
display: none;

values:
https://fi.wikipedia.org/wiki/ER-kaavio
ER-kaavio – Finnish
fi
fi
interlanguage-link-target

values:
interlanguage-link interwiki-fi
display: none;

values: உருபொருள்-உறவு மாதிரி – Tamil

values:
interlanguage-link interwiki-ta
display: none;

values: แบบจำลองความสัมพันธ์เอนทิตี – Thai

values:
interlanguage-link interwiki-th
display: none;

values:
interlanguage-link interwiki-tr
display: none;

values: Модель «сутність — зв'язок» – Ukrainian

values:
interlanguage-link interwiki-uk
display: none;

values: All languages (initial selection from common choices by you and others)

values: mediawiki ltr sitedir-ltr mw-hide-empty-elt ns-0 ns-subject page-Entity–relationship_model rootpage-Entity–relationship_model skin-vector action-view